Closed Bug 6144 Opened 26 years ago Closed 25 years ago

[DOGFOOD]HTTP basic-auth forgets authorization: hdr after 1st GET

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tbana, Assigned: jud)

References

(
URL
)

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.
Status: NEW → ASSIGNED
Assignee: chofmann → hshaw
Status: ASSIGNED → NEW
https is not hooked up yet. look for this around m8.
Target Milestone: M8
Status: NEW → ASSIGNED
Component: other → Security
QA Contact: leger → dshea
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. ;-)
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M8 → M9
Moving to M9 since re-opened.
Component: Networking-Core → Necko
Target Milestone: M9 → M10
Expect basic auth around M10.
Blocks: 12837
*** Bug 10582 has been marked as a duplicate of this bug. ***
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
*** Bug 9041 has been marked as a duplicate of this bug. ***
*** Bug 9041 has been marked as a duplicate of this bug. ***
Blocks: 7530
Blocks: 8213
Blocks: 10730
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.
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?
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.
Thanks for the pointer. I just added the same comment to 10737.
*** Bug 10113 has been marked as a duplicate of this bug. ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You should be able to login on basic-auth sites now. For wallet/single-signon related bugs please open a new one.
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
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.
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Yup... I think I have a bug already about making the auths persistent (during a session) Will find that... in the meantime, accepting this.
Target Milestone: M10 → M11
moving to m11. let me know if this is ready or becomes ready in the next few days.
Priority: P3 → P2
Summary: HTTP basic-auth forgets authorization: hdr after 1st GET → [DOGFOOD]HTTP basic-auth forgets authorization: hdr after 1st GET
Whiteboard: [PDT+]
Approved for PDT+
Blocks: 12833
No longer blocks: 12833
*** Bug 15070 has been marked as a duplicate of this bug. ***
*** Bug 15959 has been marked as a duplicate of this bug. ***
*** Bug 17143 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M12
->m12
*** Bug 17862 has been marked as a duplicate of this bug. ***
OS: Windows 98 → Windows NT
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.
OS: Windows NT → All
Won't be possible for M11. Changed platform to All.
Blocks: 18471
Blocks: 18951
Whiteboard: [PDT+] → [PDT+] 2 days
Whiteboard: [PDT+] 2 days → [PDT+] 11/19
Assignee: gagan → valeski
Status: ASSIGNED → NEW
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!)
Whiteboard: [PDT+] 11/19 → [PDT+] 11/26
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.
*** Bug 18668 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
my bad. Gagan had already checked in the auth engine files. I'm running a few sanity checks then dropping these in.
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.
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).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fix checked in 11/20/99 2:20pm pac time.
Status: RESOLVED → VERIFIED
Verified: WinNT 1999112208 comm Linux 1999112208 comm MacOS 1999112208 comm
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
No longer blocks: 18471
No longer blocks: 18951
You need to log in before you can comment on or make changes to this bug.