Closed Bug 1449112 Opened 7 years ago Closed 7 years ago

JBoss authentication issue since FF 59 (problem with accents in authentication window ?)

Categories

(Firefox :: Untriaged, defect)

59 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox59 --- affected
firefox60 --- affected
firefox61 --- affected

People

(Reporter: loic.mahe31, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180323154952 Steps to reproduce: Hello, I'm using Firefox (French version) to reach a JBoss EAP 6.4.13.GA web console. Authentication on JBoss is performed against an Active Directory through a Java API (com.sun.jndi.ldap.LdapCtxFactory). When authenticating, Firefox opens the classical popup with login and password fields. My password includes a French accent (lowercase e with grave accent). Since Firefox 59.0.1, both 32 and 64 bit versions (and I confirmed it with 59.0.2), my login is rejected. Login works with : - FF 58.0.1 and previous versions - Chrome Version 65.0.3325.181 - Internet Explorer 11.0.9600.18698. I've changed my password by removing the e with grave accent => login works again. So maybe the 59.x update broke something related to accents within the popup window ? Loïc Mahé, Toulouse, France Actual results: Authentication rejected Expected results: Authentication approved
Summary: JBoss authentication issue since FF 59 → JBoss authentication issue since FF 59 (problem with accents in authentication window ?)
I've tried to reproduce this issue using main stream login forms like: facebook.com and https://accounts.firefox.com/signin and using password containing "é", but I couldn't reproduce the issue on Firefox 59.0.2 20180323154952, so it seems this bug is also related to your setup, which overall is kinda'of hard to reproduce. Giving the above, Loïc Mahé, would you be willing to assist us further with finding a regression range for this issue? If yes, you would need to install mozregression (https://mozilla.github.io/mozregression/) and follow the documentation how to use it: (short version - once installed it will require 2 dates or two versions between which we think the the bug that caused this issue is located, and then mozregression will start downloading Firefox versions for you in which you will have to test the issue at hand and tell it afterwards which one is good and which one is bad, hopefully leading to a patch/patches that introduced this issue. (for this you would need to set your password back to using the special character with which the bug reproduces)
Flags: needinfo?(loic.mahe31)
Hello, I've run mozregression (what a fantastic tool!) and found this result: Bug 1419658 - let Basic http auth support ISO-8859-1 user/password, r=honzab Hope this helps. Loïc Mahé, Toulouse, France
Flags: needinfo?(loic.mahe31)
Thanks Loïc Mahé for the help! IMO, bug 1419658 does seem like the right regression range. Since this needs a particular environment to be reproduced, I'm not sure however on which component this bug should go to? Loïc Mahé, could you please confirm that this issue is reproducible on Nightly and Beta versions? https://www.mozilla.org/en-US/firefox/channel/desktop/) Valentin, Honza, can you please take a look over this regression?
Blocks: 1419658
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(loic.mahe31)
Flags: needinfo?(honzab.moz)
Keywords: regression
Hello, I didn't save (shame on me!) the mozregression log with the good/bad result on each version tested, but I confirm that this bug occurs on several Nightly and Beta versions. So if I understand correctly, as soon as the bug is corrected, I should test on the lastest nightly or beta version ?
Flags: needinfo?(loic.mahe31)
(In reply to loic.mahe31 from comment #4) > Hello, > > I didn't save (shame on me!) the mozregression log with the good/bad result > on each version tested, but I confirm that this bug occurs on several > Nightly and Beta versions. So if I understand correctly, as soon as the bug > is corrected, I should test on the lastest nightly or beta version ? It's fine, there is no need for the mozregression logs. My request is just to get the latest Nightly(61) and Beta(60) builds - you can download both versions here: https://www.mozilla.org/en-US/firefox/channel/desktop/ and just confirm on each of them that the bug reproduces as I'm suspecting it will. FYI, this is required in order to set the affected version flags correctly.
Flags: needinfo?(loic.mahe31)
Okay, I've just tested 60.0b9 and 61.0a1 : both reproduce the bug.
Flags: needinfo?(loic.mahe31)
(In reply to Adrian Florinescu [:AdrianSV] from comment #1) > I've tried to reproduce this issue using main stream login forms like: this is not related to web form logins, this is http authentication dialog and we have only changed basic auth. tho, may not be clear from the report. the letter has UTF-16 code U+00E8 (è) and as UTF-8 is encoded as C3A8. a quick PHP test (expecting UTF-8) shows that the request basic authentication header: - in Chrome 65.0.3325.181 and Firefox nightly (61) is encoded as UTF-8 sequence: C3A8 - in Edge 41 and IE 11 is encoded as loosely converted UTF-16 -> ANSI: E8 Hence, based on your claim that it works in IE11 I would suggest that JBoss is sniffing UA and overrides for firefox and IE. Can you please do the following and retest: - go to about:config - create a new STRING preference of name general.useragent.override - set it's value to "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" (w/o the quotes, this is what chrome sends in the User-Agent header) - try to login again while using and expecting è in the password
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(loic.mahe31)
Flags: needinfo?(honzab.moz)
I'm puzzled by the reactivity here! Honza, I tried the general.useragent.override parameter as you proposed and indeed the login works again.
Flags: needinfo?(loic.mahe31)
Thanks for confirming this is a JBoss bug. I recommend filing an issue with JBoss (The instructions are here: https://developer.jboss.org/wiki/HelpBugReport) Please post a link back here, so it can be tracked properly. Thanks a lot for working with us.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
The JBoss platform didn't change and is a bit old now (6.4.13.GA), so if JBoss is reacting to the User-Agent header, why a small change in a very recent FF's UA could have an impact? FF 58.0.1 : Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 FF 59.0.2 : Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 The patch on basic http auth support must have changed something. When you write that "IE 11 is encoded as loosely converted UTF-16 -> ANSI: E8", does this applies to all IE 11 versions ?
(In reply to loic.mahe31 from comment #10) > The JBoss platform didn't change and is a bit old now (6.4.13.GA), so if > JBoss is reacting to the User-Agent header, why a small change in a very > recent FF's UA could have an impact? That patch in bug 1419658 fixed a known issue in Firefox. JBoss it seems was parsing the user agent string, and working around that bug. Now that the bug is fixed, that workaround is actually causing the login to fail.
Nope. This is not a bug in JBoss. Firefox has changed it's default encoding, and it was kind of *expected* that this will break sites that assume Firefox will send ISO-8859-1, just as it has done since the Netscape days. See <https://greenbytes.de/tech/webdav/rfc7617.html#rfc.section.B.3>.
(In reply to Julian Reschke from comment #12) > Nope. This is not a bug in JBoss. > > Firefox has changed it's default encoding, and it was kind of *expected* > that this will break sites that assume Firefox will send ISO-8859-1, just as > it has done since the Netscape days. > > See <https://greenbytes.de/tech/webdav/rfc7617.html#rfc.section.B.3>. Thanks, this is the right summary.
So who should be blamed? Is this bug really INVALID?
(In reply to Masatoshi Kimura [:emk] from comment #14) > So who should be blamed? Is this bug really INVALID? Not sure anyone should be blamed here. We simply changed our behavior. It was expected that some sites would break. It was well announced in advance, rode the train. If something, then this should be turned to an evangelism bug.
> It was well announced in advance Does this means that the JBoss team already knows and will issue a correction (but not on old releases probably) ?
FWIW, JBoss would need to do even *more* UA sniffing, in order not to break ESR releases...
(In reply to loic.mahe31 from comment #16) > > It was well announced in advance > > Does this means that the JBoss team already knows and will issue a > correction (but not on old releases probably) ? No. You should file a bug with them. If you do, please refer it here in the "See also" or just in a comment, thanks.
FWIW, it's likely that *many* basic auth implementations out there will have the same problem (unless it was recently changed), so it might be good if the FF team actually tested that and opened bug reports (think Tomcat, httpd, IIS, etc).
Hello, I filed the bug at Red Hat : https://bugzilla.redhat.com/show_bug.cgi?id=1565013
You need to log in before you can comment on or make changes to this bug.