Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.6
    • Fix Version/s: 1.9.8
    • Component/s: Usability
    • Labels:
      None
    • Environment:
      Internet Explorer 6 through 8
    • Database:
      Any
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      31905

      Description

      When looking at obfuscated email addresses in IE6 they appear as their obfuscated form. Obfuscated email addresses in IE7 and IE8 work most of the time except when the @ symbol is obfuscated to %40 then they appear invalidly. As the obfuscation changes not all users are impacted at the same time however across a selection of users it is possible.

      See also: http://moodle.org/mod/forum/discuss.php?d=56582

        Activity

        Hide
        Helen Foster added a comment -

        Sam, thanks for your report. Assigning to moodle.com for consideration.

        Show
        Helen Foster added a comment - Sam, thanks for your report. Assigning to moodle.com for consideration.
        Hide
        Andrew Davis added a comment -

        Looking at moodle 1.9 in IE 8 email addresses are being displayed correctly on screen for me. If you hover over an email address the mailto link displayed in the progress bar at the bottom left of the browser has a %40 where the @ should be. If I click on the mailto link it it takes me to hotmail with the address corrected.

        There may be two problems for people actually obfuscated email address all the way through to their email client. IE isn't switching from the hex representation of @ to the @ character itself and people's email clients aren't doing the substitution either. Although I suppose the email client is probably correct in assuming that the browser will give it an unobfuscated email address.

        It would be easy to add checks for the @ symbol to the obfuscation functions so it is always passed through as is. That would fix this for people where the %40 is the only problem they see. For people who are seeing entirely obfuscated email addresses, IE 6 mostly by the sounds of it, this wouldn't really help.

        On the view user page (user/view.php) the user's email address is always obfuscated regardless of whether or not email protection filter is enabled. If this page checked that the email protection filter was enabled before obfuscating people could at least turn it off if they are experiencing problems.

        Show
        Andrew Davis added a comment - Looking at moodle 1.9 in IE 8 email addresses are being displayed correctly on screen for me. If you hover over an email address the mailto link displayed in the progress bar at the bottom left of the browser has a %40 where the @ should be. If I click on the mailto link it it takes me to hotmail with the address corrected. There may be two problems for people actually obfuscated email address all the way through to their email client. IE isn't switching from the hex representation of @ to the @ character itself and people's email clients aren't doing the substitution either. Although I suppose the email client is probably correct in assuming that the browser will give it an unobfuscated email address. It would be easy to add checks for the @ symbol to the obfuscation functions so it is always passed through as is. That would fix this for people where the %40 is the only problem they see. For people who are seeing entirely obfuscated email addresses, IE 6 mostly by the sounds of it, this wouldn't really help. On the view user page (user/view.php) the user's email address is always obfuscated regardless of whether or not email protection filter is enabled. If this page checked that the email protection filter was enabled before obfuscating people could at least turn it off if they are experiencing problems.
        Hide
        Sam Moffatt added a comment -

        Hi Andrew,

        Yes, it displays on screen perfectly fine regardless of browser which is the tricky bit. The problem is that underneath the browsers do strange things with the actual URL. IE6 is the major problem child and since my Uni still supports IE6 I actually did a local mod to disable the obfuscation (we only create users in Moodle who are actual students with us) on the user page since it doesn't respond to anything else. A fix for that would be nice but IMHO its a PITA not a great bug. So the IE7/IE8 @ symbol issue is a problem I'd like to see addressed which is an issue regardless. Adhering to the obfuscation setting would be nice for situations like us however for me personally I view the fact it breaks in the latest IE as a problem more than anything. IE6 support is painful but you have to draw a line somewhere.

        Cheers!

        Show
        Sam Moffatt added a comment - Hi Andrew, Yes, it displays on screen perfectly fine regardless of browser which is the tricky bit. The problem is that underneath the browsers do strange things with the actual URL. IE6 is the major problem child and since my Uni still supports IE6 I actually did a local mod to disable the obfuscation (we only create users in Moodle who are actual students with us) on the user page since it doesn't respond to anything else. A fix for that would be nice but IMHO its a PITA not a great bug. So the IE7/IE8 @ symbol issue is a problem I'd like to see addressed which is an issue regardless. Adhering to the obfuscation setting would be nice for situations like us however for me personally I view the fact it breaks in the latest IE as a problem more than anything. IE6 support is painful but you have to draw a line somewhere. Cheers!
        Hide
        Andrew Davis added a comment -

        I can think of a few alternative ways to deal with this:

        1) just dont obfuscate the @ symbol. This should hopefully fix IE 7 and 8. IE 6 will still have broken mailto links. This could also somewhat undermine whatever security is being gained through this obfuscation.

        2) Use a mail link that requires javascript. Then users without javascript simply cant send email via this link.

        3) Use a form to send email via moodle or otherwise handle the communication through moodle. A mailto link is always going to be a problem to secure. It is only necessary if you want a link in the browser that opens an external email application. If we just replace that link with a link to send the person a message within Moodle this problem goes away although then the message sender cant attach files, CC other people or use other email features.

        I cant say that any of these are definitely the way to go...

        Show
        Andrew Davis added a comment - I can think of a few alternative ways to deal with this: 1) just dont obfuscate the @ symbol. This should hopefully fix IE 7 and 8. IE 6 will still have broken mailto links. This could also somewhat undermine whatever security is being gained through this obfuscation. 2) Use a mail link that requires javascript. Then users without javascript simply cant send email via this link. 3) Use a form to send email via moodle or otherwise handle the communication through moodle. A mailto link is always going to be a problem to secure. It is only necessary if you want a link in the browser that opens an external email application. If we just replace that link with a link to send the person a message within Moodle this problem goes away although then the message sender cant attach files, CC other people or use other email features. I cant say that any of these are definitely the way to go...
        Hide
        Sam Moffatt added a comment -

        To be honest the first option appears to be the best route. IE6 is not really supported by its vendor and Microsoft are actively discouraging usage of the tool as well as doing stuff like removing IE6 support from Sharepoint. This means it will work in every other browser fine and may even confuse a spam bot somewhere as well. The second option is mostly fine but you've got a link that in part requires JS anyway due to the obfuscated email and the last option is perhaps not a bad option to have but then becomes vulnerable to other issues as well.

        Show
        Sam Moffatt added a comment - To be honest the first option appears to be the best route. IE6 is not really supported by its vendor and Microsoft are actively discouraging usage of the tool as well as doing stuff like removing IE6 support from Sharepoint. This means it will work in every other browser fine and may even confuse a spam bot somewhere as well. The second option is mostly fine but you've got a link that in part requires JS anyway due to the obfuscated email and the last option is perhaps not a bad option to have but then becomes vulnerable to other issues as well.
        Hide
        Andrew Davis added a comment -

        Sam, do you know if email addresses are actually making it all the way through to people's email client obfuscated? When you click on the email address in Moodle does it appear in the "to" area of the mail client as andrew%40moodle.com or anything like that?

        I just tested this some more in IE 6, 7 and 8 and although the mailto link displayed in the progress bar when you hover over the link is obfuscated to varying degrees when i actually click on the link the email address appears in the new email correctly. I'm tested this with Thunderbird 3.0 as my email client.

        Show
        Andrew Davis added a comment - Sam, do you know if email addresses are actually making it all the way through to people's email client obfuscated? When you click on the email address in Moodle does it appear in the "to" area of the mail client as andrew%40moodle.com or anything like that? I just tested this some more in IE 6, 7 and 8 and although the mailto link displayed in the progress bar when you hover over the link is obfuscated to varying degrees when i actually click on the link the email address appears in the new email correctly. I'm tested this with Thunderbird 3.0 as my email client.
        Hide
        Sam Moffatt added a comment -

        Unfortunately we've done a fix for the issue so I can't do much more testing - with Outlook the system was passing the incorrect data across it seemed but it is a bit hard now to validate it. Additionally due to a job shift I'm unable to see the notes I made against the issue internally. I will see if I can get someone else to have a look at this issue.

        Show
        Sam Moffatt added a comment - Unfortunately we've done a fix for the issue so I can't do much more testing - with Outlook the system was passing the incorrect data across it seemed but it is a bit hard now to validate it. Additionally due to a job shift I'm unable to see the notes I made against the issue internally. I will see if I can get someone else to have a look at this issue.
        Hide
        Andrew Davis added a comment -

        Attached is a patch. This just prevents the @ symbol being obfuscated. That should resolve the problem in IE 7 and 8. With IE 6 being on the way out Im not sure its worth majorly reworking this just for IE 6.

        Show
        Andrew Davis added a comment - Attached is a patch. This just prevents the @ symbol being obfuscated. That should resolve the problem in IE 7 and 8. With IE 6 being on the way out Im not sure its worth majorly reworking this just for IE 6.
        Hide
        Martin Dougiamas added a comment -

        Sounds like a good solution to me +1

        Show
        Martin Dougiamas added a comment - Sounds like a good solution to me +1
        Hide
        Andrew Davis added a comment -

        Committed in slight violation of testing day no commit rule. I would have got it committed earlier but our net went down
        fixed in 1.9 and trunk.

        Show
        Andrew Davis added a comment - Committed in slight violation of testing day no commit rule. I would have got it committed earlier but our net went down fixed in 1.9 and trunk.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: