Closed Bug 815446 Opened 13 years ago Closed 12 years ago

Moodle UA string override breaks Moodle-to-Mahara Single Sign-on

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox17 + verified
firefox18 + verified
firefox19 --- verified
firefox20 --- verified
firefox-esr17 - verified

People

(Reporter: MattN, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

See bug 799502 comment 21 and later. Moodle Networking (MNet) Single Sign-on (SSO) code uses a SHA1 hash of the user-agent string while looking up SSO sessions. Therefore, the client applications (e.g. Mahara) also have code to send the hashed UA string to Moodle to verify the session. With bug 799502 fixed, the hash of the UA string in Moodle doesn't match the one from the other application (e.g. Mahara) and so SSO authentication fails. Related bugs: * Mahara - https://bugs.launchpad.net/mahara/+bug/1082416 * Moodle - http://tracker.moodle.org/browse/MDL-36838
(In reply to Boris Zbarsky (:bz) from bug 799502 comment #26) > Can we simply send the same cooked-up UA to Mahara? Can we detect when > we're dealing with it? That would fix Mahara but not other MNet SSO applications. Mahara session cookies have a 'mahara' suffix with an optional prefix. https://gitorious.org/mahara/mahara/blobs/00f8030e9bb5eb1dd2269481d59daae0e5383f6f/htdocs/auth/session.php#line33
See Also: → https://launchpad.net/bugs/1082416
Assigning myself as QA contact.
QA Contact: anthony.s.hughes
(In reply to Matthew N. [:MattN] from comment #1) > (In reply to Boris Zbarsky (:bz) from bug 799502 comment #26) > > Can we simply send the same cooked-up UA to Mahara? Can we detect when > > we're dealing with it? > > That would fix Mahara but not other MNet SSO applications. How popular is Mahare in relation to other MNet SSO applications? > Mahara session cookies have a 'mahara' suffix with an optional prefix. So doing the override for Mahara would be pretty easy.
(In reply to Dão Gottwald [:dao] from comment #3) > (In reply to Matthew N. [:MattN] from comment #1) > > (In reply to Boris Zbarsky (:bz) from bug 799502 comment #26) > > > Can we simply send the same cooked-up UA to Mahara? Can we detect when > > > we're dealing with it? > > > > That would fix Mahara but not other MNet SSO applications. > > How popular is Mahare in relation to other MNet SSO applications? AFAIK, MNet is primarily used for Moodle-to-Moodle and Moodle-to-Mahara SSO. There was an attempt at an MNet library[1] and Drupal integration[1] but it is experimental and no longer maintained AFAICT. [1] https://code.google.com/p/mnet-lib/
Ok, I'm morphing this bug since it seems reasonable to focus on Mahara. We can file bugs for other scenarios if needed. Does Mahara integrate with applications other than Moodle? Would this break if we changed the UA string for Mahara?
Summary: Moodle UA string override breaks MNet SSO applications (e.g. Mahara) → Moodle UA string override breaks Moodle-to-Mahara Single Sign-on
(In reply to Matthew N. [:MattN] from comment #4) > > How popular is Mahare in relation to other MNet SSO applications? > > AFAIK, MNet is primarily used for Moodle-to-Moodle and Moodle-to-Mahara SSO. > There was an attempt at an MNet library[1] and Drupal integration[1] but it > is experimental and no longer maintained AFAICT. Agreed. Mahara will be 99% of the uses. Thanks, once again from Moodle for looking into this.
Note though, that it'd be good to get a +1 from the Mahara devs that they are happy with this. I've asked them to comment on this.
selfishly, +1, sensibly -1 This is a ridiculously slippery slope, to use an abused cliche. While I can see the justification, I'm still not comfortable with doing it.
(In reply to talktodan from comment #6) > (In reply to Matthew N. [:MattN] from comment #4) > > > How popular is Mahare in relation to other MNet SSO applications? > > > > AFAIK, MNet is primarily used for Moodle-to-Moodle and Moodle-to-Mahara SSO. > > There was an attempt at an MNet library[1] and Drupal integration[1] but it > > is experimental and no longer maintained AFAICT. > > Agreed. Mahara will be 99% of the uses. Do you mean 99% of the uses excluding Moodle-to-Moodle? I would estimate that Moodle-to-Moodle networking is more common than 1% of MNet usage since some large schools/districts use one Moodle install for common courses and authentication while separate installs are run for each faculty/department/school[3]. I've personally used it to connect 3 school Moodles to one shared district one. This use case is also broken on the first attempt since bug 799502 (see [2]). [2] http://tracker.moodle.org/browse/MDL-36838?focusedCommentId=190694&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-190694 [3] https://moodle.org/mod/forum/discuss.php?d=175158#p769465
My opinion on this. I would say revert the change done in bug 799502 and make sure that particular moodle bug is fixed. I would also say to not add more hacks to firefox just to make certain applications work properly. The applications themselves shouldn't be relying on user agents that heavily, and not be using them as a "security" mechanism as is the case with MNet. Other browsers, such as Chromium/Chrome, Safari, Internet Explorer haven't done any UA tweaking that has affected Moodle or Mahara to my knowledge, so I don't see any reason why firefox should take a different approach. The bug is in the web applications, not the browser. It is akin to saying that if a trailer on a car is not working because the tow ball no longer works, we should fix the road they use, not the tow ball. That is just plain wrong, we should fix the cause of the issue, which lies in the Moodle and Mahara code bases. It is for that reason why I suggest that bug 799502 should be reverted, so the onus of that Moodle bug lies back on Moodle, and that this bug should be closed as wontfix and should be fixed in Moodle and Mahara. Cheers, Hugh Mahara Developer
Hugh, the Moodle bug is being fixed or has been already. Do you have a proposed deployment plan that will update Moodle installs that are out there so that our users don't have to deal with the breakage?
(In reply to hugh from comment #10) > Other browsers, such as Chromium/Chrome, Safari, Internet Explorer haven't > done any UA tweaking that has affected Moodle or Mahara to my knowledge, so > I don't see any reason why firefox should take a different approach. The bug > is in the web applications, not the browser. Although other browsers may not affect this particular application, at least IE and Opera change the behavior heavily depending on the site. http://my.opera.com/core/blog/show.dml/3130540 Of course it doesn't mean we should follow their approach. I agree your proposal in principle.
WebKit also has lots of site-specific hacks, actually. I agree it's suboptimal to do it; I just don't see a better solution here. Again, if there is a credible deployment plan for updated Moodle versions I'd love to hear about it!
Hi Boris, I would agree with comment 23 on bug 799502. > I understand this workaround was implement to avoid trouble for some users, but > for other users this is even worse. Why not fix the problem at the right place > (Moodle), to avoid the risk of more side effects? Bug 799502 was to fix an issue to do with getting a rich text editor instead of a plain text editor. No idea why that would rely on a user agent, but this is not the time for that discussion ;). (http://tracker.moodle.org/browse/MDL-35469 btw) I would say this MNet breakage is a lot more critical than a lowly editor change. Users can still edit text with a plain text editor, though may be limited. If they find themselves limited too much, they can choose another browser temporarily. If, however, a user cannot roam to another application such as Mahara, which is commonly used in academic situations where a user has to complete one task on Moodle and one on Mahara, then they find themselves completely limited with bug 799502 (or any UA hack) in place. If all these UA hacks are removed, MNet works fine, but the editor only shows only plain text for Moodles that have not yet updated to the newer version. In this state, the user would still have all the functionality they had before, with a limitation that they can't see pretty buttons to edit their rich text. So my deployment plan would be to remove any UA hacks from the browser, which is expected to give a consistent result to any application IMHO, and then any users that have upgraded to firefox 17 can simply upgrade again to the next version (which they appear to being quite up to date if they are already on firefox 17). As for the rich text editor, a fix for that was released in October aiui, and if users really care about a aesthetic change, they should bug their administrators to grab that patch. If you decide to ignore me, and just put in another UA hack, I ask one question, where will it stop... Cheers, Hugh
As for other browsers tweaking dependant on site, I assumed there were, just none that affected Moodle and Mahara, so I never noticed them. I would still argue that a web application that is broken shouldn't be fixed on the browser level, but on the web application level. Otherwise where do you stop... The point of putting out new releases of web applications is to grow their features and fix bugs. If some of those bugs are critical, then they should be fixed at the application level and released to the public and the public should then take whatever action they deem appropriate for their particular situation. It should not get referred up to the browser level to get it fixed there... that is, and never will be the right place IMHO. As a user of open source software, I have used many things that didn't work quite right, and there have been instances where it could be fixed by fixing some other application that happens to be loosely related to the broken application. That is not what that happens in my experience, the bug is fixed in the broken application in question. Cheers, Hugh
Hugh, so far that deployment plan mostly sounds like "just have Moodle users use some other browser"... As for where one stops, that's always a hard question. I would like to think that a hack like this is temporary, just to give Moodle installs time to upgrade. Again, no one is suggesting that this NOT be fixed in Moodle. The only question is how to minimize user pain while the fix is getting rolled out.
(I'm the Moodle lead developer) I totally agree with Boris here. Yes, we will fix (and partially have fixed) all this in new Moodle and Mahara versions, and will do everything in our power to get users to upgrade, and in the ideal world we all agree on they all will do that. But in reality institutions very often won't, or can't, for many reasons. So as said above, we are just trying to minimise user pain in the short term. I'm very grateful that the Firefox folk are willing to help us with this, it makes all three open source projects look better to users. So my +1 for a similar UA fix in Firefox for Mahara, assuming that some senior Mahara people can test and confirm that it's not going to break anything else!
Hi Boris, My deployment plan would be: If they users care so much about a rich text editor vs a plain text, then bug their admin to get that patch. The MNet should not be an issue if bug 799502 is reverted. A change of browsers is also a viable solution for some, not for others. I'm sure there could be a bundle of bugs affecting the rich text editor that did not rely upon the firefox browser, so what happens when Moodle gets those bugs? I think the word "hack" should give the answer. "hacks" should not go into good products. "hacks" should be avoided. But... If this is just a "temporary hack", then when does it get rolled back. I will note that 1.9 is no longer supported for new features and minor bug fixes, and will soon reach end of life completely. I also know of some clients on versions < 1.9... Does mozilla still support them, how long for? Cheers, Hugh
> If they users care so much about a rich text editor vs a plain text, then bug their admin No, they'll just assume Firefox is broken (especially since the problem started with a Firefox update) and switch browsers. We have pretty good data on that sort of thing: it's very rare for users to think a website is broken, especially if it breaks after a browser update. They just blame the browser (with good reason!). > "hacks" should not go into good products. Hugh, there are tons of "hacks" in "good" products. We have dozens of workarounds around compiler bugs in our codebase, a number of workarounds around broken web servers, and so forth. So does any other "good" product. Any time you have to interface with someone else's potentially buggy code you may end up having to put in a temporary workaround for its bugs, while waiting for the other party to fix its end. Obviously it's better if that can be avoided, but sometimes it really is the least bad choice. > then when does it get rolled back. This is an excellent question. If the Moodle team can give us some sort of indication of how many Moodle installs have been updated, that would be a good basis for that sort of decision. In general, it's very hard to make broadly-applicable policy for issues like this; they tend to be handled on a case-by-case basis. Which works, because they're pretty rare.
(In reply to Boris Zbarsky (:bz) from comment #19) > > If they users care so much about a rich text editor vs a plain text, then bug their admin > > No, they'll just assume Firefox is broken (especially since the problem > started with a Firefox update) and switch browsers. We have pretty good > data on that sort of thing: it's very rare for users to think a website is > broken, especially if it breaks after a browser update. They just blame the > browser (with good reason!). That makes sense. I would agree with that. > > > "hacks" should not go into good products. > > Hugh, there are tons of "hacks" in "good" products. We have dozens of > workarounds around compiler bugs in our codebase, a number of workarounds > around broken web servers, and so forth. So does any other "good" product. > Any time you have to interface with someone else's potentially buggy code > you may end up having to put in a temporary workaround for its bugs, while > waiting for the other party to fix its end. Obviously it's better if that > can be avoided, but sometimes it really is the least bad choice. Also valid point. I'm just aware that this is adding a hack thatis because of another hack that broke more things that was intended to fix.. > > > then when does it get rolled back. > > This is an excellent question. If the Moodle team can give us some sort of > indication of how many Moodle installs have been updated, that would be a > good basis for that sort of decision. What about users that never upgrade (and haven't even gone to 1.9) Also. What fallout will happen when this finally does get reverted. > > In general, it's very hard to make broadly-applicable policy for issues like > this; they tend to be handled on a case-by-case basis. Which works, because > they're pretty rare. I think I'll give a reluctant +1 here but only if what I'm saying gets to someone. Also, would we be able to get a copy of what the hack does, so we are not in the same positio in a few weeks. Cheers, Hugh
> What about users that never upgrade (and haven't even gone to 1.9) The only hope there is that as time passes there will be fewer and fewer of those. > What fallout will happen when this finally does get reverted. With any luck, strictly less than if we didn't put the hack in place. Guaranteeing that is hard, of course. :( Again, I don't think anyone is happy with the current situation and the available options....
I would still be interested in seeing the hack for moodle as that may of broken stuff we still don't know about. If more stuff is broken it would look bad on mozilla as boris stated earlier. Cheers, Hugh
Unless we do an interim security release, any fix for this bug in Firefox would be released with Firefox 18, currently scheduled for the 6th of January. If we think that by that time it's not worth doing because most sites will have taken updated versions of Moodle and/or Mahara, then we can close this bug and not bother. Otherwise, we should prepare a patch which treats Mahara cookies like Moodle cookies, and see if it solves the problem. Is anyone CCed on this bug able to provide a set of steps to reproduce, perhaps on a test Moodle installation, with a username and password that they are able to publish, so QA can do testing? Gerv
Another option would be to limit the Moodle override to pages with an editor, assuming that's a known set of pages with fixed names (edit.php or whatever).
There is not a simple heuristic for which Moodle pages might contain the HTML editor.
You could limit the moodle hack to all pages except /auth/mnet/jump.php and /auth/mnet/land.php ?
(In reply to Gervase Markham [:gerv] from comment #23) > If we think that by that time it's not worth doing because most > sites will have taken updated versions of Moodle and/or Mahara, then we can > close this bug and not bother. We cannot assume that all Moodle and Mahara installations will be updated by then. Moodle publishes security updates every other month and the next ones for the currently supported versions are due at the beginning of January. For Mahara we publish security updates that may contain other important bug fixes when necessary. Though we publicize security updates widely, not every admin updates (immediately), and we cannot force them to do so. We can only encourage them. This time of the year may be esp. difficult as people are preparing for the holidays (and summer vacation here in the Southern hemisphere) and thus updates may not be applied swiftly to the applications though it would seem useful. I'm afraid we don't have any statistics of how many of the institutions that use Mahara and Moodle or connect Moodles via MNet use Firefox and would be affected not even to speak of the personal computers of the users. > Is anyone CCed on this bug able to provide a set of steps to reproduce, > perhaps on a test Moodle installation, with a username and password that > they are able to publish, so QA can do testing? As for Mahara, we have an instance that we can use. I'll just have to find a public Moodle to connect it to. Our demo site is self-resetting and that might affect the MNet connection. Will get back to you once I talked to our developers.
It's been decided to back this change out in a 17.0.1 release (with some other compatibility fixes) - see bug 815743. However, updates which make sites work well when the user agent does not contain Gecko/<date> are still necessary to make the sites work with Firefox for Android and Firefox OS. So, please continue to make them. The update to MNet to not use the UA as a hash key may not still be necessary, but I'd suggest changing it anyway! :-) Thank you for your patience and understanding :-) Gerv
Hi Gerv, Thanks for letting us know. Out of interest, is there some discussion of your decision to reverse this change in UA? I can't see it in bug 815743. cheers, Dan
Hi Dan, The decision was made at what's called the "channel meeting", which happens on Tuesdays at 10am Pacific Time. They were looking at all the compatibility issues with Firefox 17, including this one. I wasn't there, as the timing is bad for me (I'm in the UK) but I submitted a report for the agenda: https://etherpad.mozilla.org/channel-mtg-agenda . It looks like that Etherpad gets cleared after each meeting, but here's the agenda and meeting notes from Tuesday: https://etherpad.mozilla.org/ep/pad/view/channel-mtg-agenda/rev.7104 See under "Roundtable" for my report. Gerv
(In reply to Gervase Markham [:gerv] from comment #30) > The decision was made at what's called the "channel meeting", which happens > on Tuesdays at 10am Pacific Time. They were looking at all the compatibility > issues with Firefox 17, including this one. I wasn't there, as the timing is > bad for me (I'm in the UK) but I submitted a report for the agenda: > https://etherpad.mozilla.org/channel-mtg-agenda . FWIW this particular decision was actually made at the 11am development meeting: https://wiki.mozilla.org/Platform/2012-11-27#Notices.2FSchedule
QA is having trouble testing the backout in bug 815743 as the websites require user accounts. We've tested the Moodle Demo website and this appears to have been fixed using the latest Nightly, Aurora, and 18.0b2 candidate. Can we get some people who were experiencing this to do some testing in parallel? QA is tracking the testing we've been trying here: https://etherpad.mozilla.org/moodle-testing Nightly: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ Aurora: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/ Beta: ftp://ftp.mozilla.org/pub/firefox/nightly/18.0b2-candidates/build1/ We'll also need help confirming 17.0.1 and 17.0.1esr builds (yet to be built): ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.1-candidates/build1/ ftp://ftp.mozilla.org/pub/firefox/nightly/17.0.1esr-candidates/build1/
Tracking - we'll need to confirm this is no longer an issue after 17.0.1 builds are available with the UA change backed out.
tracking-firefox17: ? → +
tracking-firefox18: ? → +
Added a Mahara -> Moodle roaming site with credentials to the Etherpad for testing purposes.
(In reply to Kristina Hoeppner from comment #34) > Added a Mahara -> Moodle roaming site with credentials to the Etherpad for > testing purposes. I'm not seeing where this information is located. Can you please add the link to the test site and the credentials to this bug report? Just put them in a comment.
:ashughes She added it as [anitsirk]
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #35) Sorry, didn't want to post it in multiple places. You can use http://master-mahara.catalystdemo.net.nz/ (test:demo) to roam to a Moodle site testing the MNet connection from Mahara to Moodle. Just click on the link in the block "Network servers" on the right-hand side when you are logged in.
(In reply to Kristina Hoeppner from comment #37) > You can use http://master-mahara.catalystdemo.net.nz/ (test:demo) to roam to > a Moodle site testing the MNet connection from Mahara to Moodle. Just click > on the link in the block "Network servers" on the right-hand side when you > are logged in. Thank you. I've tested and this site works for me in Firefox 17.0.1.
We tested this extensively during 17.0.1 and 17.0.1esr qualification. I think it's safe to mark this verified.
Status: RESOLVED → VERIFIED
status-firefox17: fixed → verified
status-firefox18: fixed → verified
status-firefox19: fixed → verified
status-firefox20: fixed → verified
status-firefox-esr17: fixed → verified
You need to log in before you can comment on or make changes to this bug.