POST request sends no parameters if NTLM is involved

RESOLVED FIXED in Firefox 50

Status

()

Core
Networking
RESOLVED FIXED
a year ago
11 months ago

People

(Reporter: bugzilla, Assigned: mayhemer, NeedInfo)

Tracking

({regression})

50 Branch
mozilla51
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox48 unaffected, firefox49 unaffected, firefox-esr45 unaffected, firefox50 fixed, firefox51 fixed)

Details

(Whiteboard: [necko-active], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 /
Build ID: 20160809004002

Steps to reproduce:

I developed PHP pages that use NTLM to get the user name of the windows client. The web interface is making use of AJAX with jQuery.
In version 50.0a2 of the developer edition (maybe earlier) XHR POST requests don't work anymore. In the common release v48 it is still working.
My NTLM routine in PHP is quite old so I have to set network.auth.force-generic-ntlm-v1 to true.


Actual results:

In PHP I get a POST request with no data at all. It also looks different in the Network module of the developer tools: in version 50.0a2 I only see two requests: the first one gets the 401 response of the server and still has the parameters set by the JavaScript. The second request has the 200 response but no parameters and accordingly the response of a "disappointed" PHP script. :-)


Expected results:

Like in version 48 of the "normal" version the POST request should keep its parameters throughout the NTLM ping-pong. In the network module I see three requests: two with 401 response and the last one with 200 response. All three show the parameters set by the JavaScript.

If it helps I can post the source code of the PHP implementation of the NTLM handshake but I don't think that the problem is there because it worked fine so far and still does in v48 and also in a recent Chrome.
I tried it in v48 and v50.0a2 on Linux (by manually entering user name and password) with newly created profiles, so no extensions or Windows madness involved. I just turned network.auth.force-generic-ntlm-v1 to true to work with my server side scripts.
(Reporter)

Updated

a year ago
Component: Untriaged → General
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
(Reporter)

Comment 1

a year ago
Sorry for not daring to think that this would also affect a POST request without XHR. You can test it on https://latzinator.com/post_test.php. You can enter whatever you like when prompted for credentials.
(Reporter)

Updated

a year ago
Summary: XHR POST request sends no parameters if NTLM is involved → POST request sends no parameters if NTLM is involved
(Reporter)

Updated

a year ago

Comment 2

a year ago
Dragana, can you look into this?
Component: General → Networking
Flags: needinfo?(dd.mozilla)
Keywords: regression
Product: Firefox → Core
Honza, IIRC you know a bit about NTLM. Can you take a look at this and re-assign or re-triage as appropriate?
Flags: needinfo?(dd.mozilla) → needinfo?(honzab.moz)
Whiteboard: [necko-active]
(Assignee)

Comment 4

a year ago
(In reply to bugzilla from comment #1)
> Sorry for not daring to think that this would also affect a POST request
> without XHR. You can test it on https://latzinator.com/post_test.php. You
> can enter whatever you like when prompted for credentials.

I need some more info.  What is the expected script behavior?  On Windows, in chrome dev and edge the page asks for creds and then fails to load (unreachable).  In fx it returns "message 01" as a response content with force-generic-ntlm-v1 = true.

Honestly, I would more appreciate your PHP script to run it locally.
Assignee: nobody → honzab.moz
Flags: needinfo?(honzab.moz) → needinfo?(bugzilla)
(Reporter)

Comment 5

a year ago
Created attachment 8781411 [details]
simple php script that POSTs to itself and uses NTLM auth
(Assignee)

Comment 6

a year ago
Thanks, going to try it out!
Flags: needinfo?(bugzilla)
(Assignee)

Comment 7

a year ago
Sorry, but I still find the test case pretty insufficient.  I absolutely don't understand how it works, what I'm suppose to do.  It behaves the same way as on your web when I host it locally.  I can't even get to the point to see the form and to try a POST.

I appreciate the effort and believe there is a bug, but to reproduce exactly what you do I simply need something more 'complete' yet still minimalistic.
Flags: needinfo?(bugzilla)
(Reporter)

Comment 8

a year ago
hm, that's strange. If I load the page I get presented with an auth dialog and if I enter something I get to the form. As I mentioned you have to set network.auth.force-generic-ntlm-v1 to true in about:config to make it work. I have not yet searched for a more modern implementation because it worked quite nicely so far.
If you then enter something in the form and submit it, Firefox will reuse the credentials and do the POST. Then the script shows what it got.
This also works for me in Chrome 52 on Linux. I guess on a Windows client the browser would automatically forward the user information with a hashed password instead. At least if the script runs on a trusted domain. Otherwise there should also be a dialog for username and password.
I don't know how to reduce this even further because I just "reused" the routine for NTLM. :-)
(Assignee)

Comment 9

a year ago
(In reply to bugzilla from comment #8)
> hm, that's strange. If I load the page I get presented with an auth dialog
> and if I enter something I get to the form. As I mentioned you have to set
> network.auth.force-generic-ntlm-v1 to true in about:config to make it work.
> I have not yet searched for a more modern implementation because it worked
> quite nicely so far.

I did that.

> If you then enter something in the form and submit it, Firefox will reuse
> the credentials and do the POST. Then the script shows what it got.
> This also works for me in Chrome 52 on Linux. I guess on a Windows client
> the browser would automatically forward the user information with a hashed
> password instead. At least if the script runs on a trusted domain. Otherwise
> there should also be a dialog for username and password.
> I don't know how to reduce this even further because I just "reused" the
> routine for NTLM. :-)

OK, i do some more experiments of my own, will report later.
(Assignee)

Comment 10

a year ago
Confirmed on 50.

Definitely something fishy going on here.  It's intermittent, first idea is 
something with connection persistence and timeout, but need to look into logs to 
find for sure.
Status: UNCONFIRMED → NEW
status-firefox48: --- → unaffected
status-firefox49: --- → unaffected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → unaffected
Ever confirmed: true
Flags: needinfo?(bugzilla)
(Assignee)

Comment 11

a year ago
Regression from bug 1264566.  Apparently when we are doing authentication loops in the http channel, we can't just drop mUploadStream (carrying the form data) in OnStopRequest that easily.
Blocks: 1264566
Status: NEW → ASSIGNED
(Assignee)

Comment 12

a year ago
Created attachment 8781996 [details] [diff] [review]
v1 (don't release upload stream when auth is pending)

selfexplanatory.  no need for a try push, we (apparently) don't have tests for this at all...

manually tested with own test case, ran net xpc tests.
Attachment #8781411 - Attachment is obsolete: true
Attachment #8781996 - Flags: review?(valentin.gosu)
(Assignee)

Updated

a year ago
Duplicate of this bug: 1293987
(Assignee)

Updated

a year ago
OS: Linux → All
Hardware: x86_64 → All
Comment on attachment 8781996 [details] [diff] [review]
v1 (don't release upload stream when auth is pending)

Review of attachment 8781996 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8781996 - Flags: review?(valentin.gosu) → review+
(Assignee)

Updated

a year ago
Keywords: checkin-needed

Comment 15

a year ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8cc4907776c8
Don't release upload stream in HTTP channel until authentication loop is done. r=valentin
Keywords: checkin-needed

Comment 16

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8cc4907776c8
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox51: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Blocks: 1302717
(Assignee)

Comment 17

a year ago
Comment on attachment 8781996 [details] [diff] [review]
v1 (don't release upload stream when auth is pending)

Approval Request Comment
[Feature/regressing bug #]: 1264566 (on 50, m-b)
[User impact if declined]: broken POST when Negotiate/NTLM authentication is involved
[Describe test coverage new/current, TreeHerder]: no automated, not NTLM tests.. but it's for a long time on m-c (just merged to m-a)
[Risks and why]: very low, if none
[String/UUID change made/needed]: none

Sorry for requesting approval that late, but I was confused what all versions were affected with this bug.
Attachment #8781996 - Flags: approval-mozilla-beta?
(Assignee)

Updated

a year ago
Duplicate of this bug: 1293628
(Assignee)

Updated

a year ago
Duplicate of this bug: 1302717
No longer blocks: 1302717
Blocks: 1304056
Hello there, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(bugzilla)
Comment on attachment 8781996 [details] [diff] [review]
v1 (don't release upload stream when auth is pending)

Recent regression in Fx50, has been in Nightly for a month, Beta50+
Attachment #8781996 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment 22

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/88fa08847a2f
status-firefox50: affected → fixed
(Reporter)

Comment 23

a year ago
(In reply to Ritu Kothari (:ritu) from comment #20)
> Hello there, could you please verify this issue is fixed as expected on a
> latest Nightly build? Thanks!

Sorry, totally overlooked that one. Yes, I can confirm that it worked as soon as it got released on Aurora channel.

Comment 24

11 months ago
I also try in Firefox Nightly 53.0a1 (2017-01-08) (64-bit)
You need to log in before you can comment on or make changes to this bug.