Basic Authentication fails for site (see test URL)

VERIFIED DUPLICATE of bug 20814

Status

()

Core
Networking
P3
normal
VERIFIED DUPLICATE of bug 20814
19 years ago
10 years ago

People

(Reporter: Christopher Cook, Assigned: Judson Valeski)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
Tried logging in using the username "chrisc" and the password "test" to the
above test URL. Basic Authentication appears to fail and the user is prompted
for login details again.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M12
(Assignee)

Comment 1

19 years ago
The authorization header we're sending is identical to the one sent in 4.x;
except that the 'a' is not capitalized (it is in 4.x) per the 1.1 HTTP RFC.
Assuming IIS isn't case sensitive WRT headers, it can only be one of two other
differences: mozilla's "accept" header is sent as "*/*" rather than outlining
various MIME types it can handle, and it is not sending the "connection" header.
I suspect that IIS is choking on one of these latter issues (note: that both are
legal).

You might want to try turing connection keep-alive (caching) off on the IIS
server. If that doesn't do it then the problem is most likely a bug in IIS (that
we may need to work around) handling of authentication and accept header
handling.
(Assignee)

Comment 2

19 years ago
of course the user agent differs as well, but let's hope IIS isn't choking on
that :/.
(Reporter)

Comment 3

19 years ago
I've tried disabling connection keep-alive on a different server (can't play
with the example one too much)
It may well be an IIS thing, but the site uses an activex control for
authentication from a database. Maybe the control is at fault (maybe not)
the control can be donwloaded as an eval from
http://www.flicks.com/flicks/authx.htm
(Assignee)

Comment 4

19 years ago
ahhh. That control is most likely the problem. I doubt it can handle the new
user agent, and/or the lowercase 'a'. I would be suprised if IIS was having this
problem.
(Assignee)

Comment 5

19 years ago
I'm contacting the control company.
(Assignee)

Comment 6

19 years ago
I'm adding Kevin (w/ AuthentiX) to this bug. Kevin if you do not want to receive
this traffic, click the bugzilla url, remove yourself from the "cc:" list and
hit submit.

AuthentiX is doing a case sensitive compare of the "authentication" header, thus
it never authenticates.
(Assignee)

Updated

19 years ago
Target Milestone: M12 → M13

Comment 7

19 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 8

19 years ago
*** This bug has been marked as a duplicate of 20814 ***

Updated

19 years ago
Keywords: verifyme

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 9

19 years ago
[bugday]marking verified. same bug indeed. and currently worksforme on my own
webserver - although the chrisc site doesn't appear to like that user/pass combo
anymore.

Updated

10 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.