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

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[loic.mahe31]

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

Comment 1

[Adrian Florinescu [:aflorinescu]]

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)

Comment 2

[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

Comment 3

[Adrian Florinescu [:aflorinescu]]

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?

Comment 4

[loic.mahe31]

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 ?

Comment 5

[Adrian Florinescu [:aflorinescu]]

(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.

Comment 6

[loic.mahe31]

Okay, I've just tested 60.0b9 and 61.0a1 : both reproduce the bug.

Comment 7

[Honza Bambas (:mayhemer)]

(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

Comment 8

[loic.mahe31]

I'm puzzled by the reactivity here!
Honza, I tried the general.useragent.override parameter as you proposed and indeed the login works again.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 10

[loic.mahe31]

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 ?

Comment 11

[Valentin Gosu [:valentin] (he/him)]

(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.

Comment 12

[Julian Reschke]

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>.

Comment 13

[Honza Bambas (:mayhemer)]

(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.

Comment 14

[Masatoshi Kimura [:emk]]

So who should be blamed? Is this bug really INVALID?

Comment 15

[Honza Bambas (:mayhemer)]

(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.

Comment 16

[loic.mahe31]

> 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) ?

Comment 17

[Julian Reschke]

FWIW, JBoss would need to do even *more* UA sniffing, in order not to break ESR releases...

Comment 18

[Honza Bambas (:mayhemer)]

(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.

Comment 19

[Julian Reschke]

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).

Comment 20

[loic.mahe31]

Hello,

I filed the bug at Red Hat : https://bugzilla.redhat.com/show_bug.cgi?id=1565013