Closed
Bug 6144
Opened 25 years ago
Closed 25 years ago
[DOGFOOD]HTTP basic-auth forgets authorization: hdr after 1st GET
Categories
(Core :: Networking, defect, P2)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: tbana, Assigned: jud)
References
()
Details
(Whiteboard: [PDT+] 11/26)
Anytime you visit a webpage with a secure login such as beta.berksys.com/login
you are not prompted with the box to enter the password thus you recieve that
you are not authorized to enter the site. This occurs on build ID:1999042908
(May 7 nightly build) The build is running on Windows 98 with all updates to
the OS installed. I can reproduce this on any page that has a secure login.
Updated•25 years ago
|
Assignee: chofmann → hshaw
Status: ASSIGNED → NEW
Comment 1•25 years ago
|
||
https is not hooked up yet. look for this around m8.
Updated•25 years ago
|
Target Milestone: M8
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee: hshaw → gagan
Status: ASSIGNED → NEW
Component: Security → Networking Library
I think this is reference to Basic-Auth not SSL. Basic-Auth is not
https/SSL/encrypted. It's a clear-text pw. This would probably be handled by
the client , netlib/N2 module to be more specific.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.
Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change. If this happens, I will fix. ;-)
Updated•25 years ago
|
Summary: Any page which has a secure login whill report that authorization failed → Any page which has a secure login will report that authorization failed
Comment 9•25 years ago
|
||
This is an M10 bug and the M10 deadline has passed. Any further delay will
jepordize an important feature in single signon from being in the M11 beta
release -- namely the ability to capture and prefill passwords from login forms
generated by the browser. The authentication feature described here, as well as
authentication for ftp protocol, are places where the browser generates such
login forms.
Can you give me a realistic date as to when this bug will be fixed.
Comment 10•25 years ago
|
||
To save time, let me propose the following. Instead of using the nsIPrompt
interface when you implement this authentication, use the single-signon
interface instead. It's the same API (same name, almost the same parameters)
and puts up the same prompt dialog. Only difference is that it gives single
signon a chance to autofill and capture the password. It will take you the same
amount of time to hook up either interface and it will save me the time of later
converting over what you have done.
Same applies to ftp authentication. Is there an open bug on that or do I assume
that this bug covers fpt as well as http authentication?
Comment 11•25 years ago
|
||
This bug should refer only to the issue of getting http passwords (Basic-Auth)
working. Bug 10737 (http://bugzilla.mozilla.org/show_bug.cgi?id=10737) discusses
ftp authentication.
Comment 12•25 years ago
|
||
Thanks for the pointer. I just added the same comment to 10737.
Comment 13•25 years ago
|
||
*** Bug 10113 has been marked as a duplicate of this bug. ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 14•25 years ago
|
||
You should be able to login on basic-auth sites now. For wallet/single-signon
related bugs please open a new one.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Summary: Any page which has a secure login will report that authorization failed → HTTP basic-auth forgets authorization: hdr after 1st GET
Comment 15•25 years ago
|
||
This isn't really fixed. While the browser now sends an HTTP authorization:
header on the first GET after authentication, it then forgets to send them on
subsequent GETs to the same realm. One place where this hurts particularly is
that the first thing returned by the Netscape admin server after authentication
is a redirect; this means that Mozilla still can't be used with the Netscape
admin server at all. I've also changed the summary on this bug to be more
precise about what's going on.
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 16•25 years ago
|
||
Yup... I think I have a bug already about making the auths persistent (during a
session) Will find that... in the meantime, accepting this.
Updated•25 years ago
|
Target Milestone: M10 → M11
Comment 17•25 years ago
|
||
moving to m11. let me know if this is ready or becomes ready in the
next few days.
Updated•25 years ago
|
Priority: P3 → P2
Updated•25 years ago
|
Summary: HTTP basic-auth forgets authorization: hdr after 1st GET → [DOGFOOD]HTTP basic-auth forgets authorization: hdr after 1st GET
Comment 18•25 years ago
|
||
Approved for PDT+
Comment 19•25 years ago
|
||
*** Bug 15070 has been marked as a duplicate of this bug. ***
Comment 20•25 years ago
|
||
*** Bug 15959 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
*** Bug 17143 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
->m12
Comment 23•25 years ago
|
||
*** Bug 17862 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
OS: Windows 98 → Windows NT
Comment 24•25 years ago
|
||
Can this be fixed for M11. It would allow more testing of the beta version?
In the 7 Nov build when the authentication box appears and you enter some
username/password the whole browser (all threads/windows) become inaccessible
(I waited 20 minutes).
In the previous build at least after entering username/password you could get
'Unauthorized' response.
Comment 25•25 years ago
|
||
Won't be possible for M11. Changed platform to All.
Comment 26•25 years ago
|
||
Am handing over all the work done for this to Judson. Most of this is in place.
Essentially I added the nsAuthEngine class that keeps track of session based
authentication sets (a set being a uri, username, password, realm and the
authstring) The nsHTTPChannel and nsHTTPRequest use this class to add the auth
header to a request. (and based on a successful login which is not 401, a set is
added to the cache)
I won't be able to watch-over the checkin and so all of this is going to Judson
(who would also gladly code review it :) Thanks Jud!)
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] 11/19 → [PDT+] 11/26
Assignee | ||
Comment 27•25 years ago
|
||
Gagan sent me his diffs for this, but forgot the nsAuthEngine header and source
file. If anyone can access his linux box and look for nsAuthEngine files, that
would be great.
Assignee | ||
Comment 28•25 years ago
|
||
*** Bug 18668 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 29•25 years ago
|
||
my bad. Gagan had already checked in the auth engine files. I'm running a few
sanity checks then dropping these in.
Assignee | ||
Updated•25 years ago
|
Assignee | ||
Comment 30•25 years ago
|
||
ouch. This is a bigger problem than anticipated. Gagan's changes provide for
persistent (in memory) authentication caching. These changes work great.
However, because of the asynchronous nature of our URL loading we're still
getting multiple auth dialogs for a given page (see provided URL).
<time passed>
Ok. I was able to get around this by caching the auth entry earlier (immediately
after we parse a successful code from teh HTTP response). I'll check in in the
morning.
Assignee | ||
Comment 31•25 years ago
|
||
we're in great shape now. we can handle multiple images in an auth requiring
root doc, no images, and a redirect after a successful auth challenge response
session. You can click cancel or enter bad data and you get expected behavior
(cancel stops loading URL, and bad data spits the prompt back at you).
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 32•25 years ago
|
||
fix checked in 11/20/99 2:20pm pac time.
Comment 33•25 years ago
|
||
Verified:
WinNT 1999112208 comm
Linux 1999112208 comm
MacOS 1999112208 comm
Comment 34•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
You need to log in
before you can comment on or make changes to this bug.
Description
•