Open Bug 547871 Opened 14 years ago Updated 3 years ago

Previously authed credentials must be entered again if another set of credentials for the same site is authed.

Categories

(Core :: Networking: HTTP, defect, P5)

x86
Windows 7
defect

Tracking

()

People

(Reporter: alta88, Unassigned)

Details

(Whiteboard: [necko-backlog])

asycAuthPrompt challenges for previously entered credentials (stored in loginmanager or session cached) if a different username/pwd is used on the same site.  a related bug may be Bug 533412 and username not being a key.

this happens even if the previously authed username is sent in a GET, eg username1@site.com/username1Info.xml and an Authentication header has been set via setRequestHeader() in the request.  

an example of this can be seen by created 2 twitter accounts, then using Fx to preview the RSS feed associated with each, and inserting the userid into the url.
alta88, could you please provide a detailed list of STR to reproduce this?  I'm not quit sure I understand all you say in the description.
sure.  in general, i'm having a hard time with auth in the case of multiple usernames for the same site (host) and realm.  testing for rss feeds needing auth and direct login has been with twitter, within an extension.

1. at twitter.com, create a twitter account, test111 eg.  post a few update messages.  note the url of the RSS Feed on the home page, it will be in the format:
http://twitter.com/statuses/friends_timeline/11111111.rss eg.
2. logout and create a second account, test222 eg. repeat above; RSS Feed should be in the format:
http://twitter.com/statuses/friends_timeline/22222222.rss eg.  logout.
3. create a url for the first username, test111, in the format:
http://test111@twitter.com/statuses/friends_timeline/11111111.rss
and enter it in urlbar to elicit an auth prompt. use test111 for username.  on auth you will see the Fx feed preview page with user111 messages.
4. do the same for test222, in the format:
http://test222@twitter.com/statuses/friends_timeline/22222222.rss
on auth with username test222 you'll see test222 messages.
5. go back in history or reload test111 url.  you will be prompted for auth.  there should be no prompt.

this is the easiest example of STR i can think of, but i'm doing the equivalent in an rss and twitter subscription extension, with polled GETs for subscribed usernames/urls at some interval.  i have an asyncAuthPrompt function and put up a custom dialog on initial subscribe which offers to save the password - hardly acceptable to the user to then repeat already saved passwords if another username is subscribed..

a secondary issue is that if user111 is already authed, then a request to GET user222's info, initially, by GETting http://twitter.com/statuses/friends_timeline/22222222.rss makes the server assume the auth is user111 and thus the wrong info is returned.  now, this is likely a design flaw at twitter.  so i want to remove all auths for the domain, so the GET request without user222@ will cause a prompt (on next attempt at user111's url the username and password are filled in from saved loginmanager authInfo, so no prompt need appear for that account).  however, due to Bug 287957 i can't clear the domain's authCache (doing clearAll() is not acceptable though i may have to do it anyway).

note that once the 2 different usernames are saved (in login manager), an Fx restart causes things to work as i fill in the url with the username and set username and password from loginmanager on the Authorization header prior to send().  so the authCache design may be the problem, as it's not based on username/host/realm key.  and workarounds aren't possible since things like nsHttpAuthCache::ClearAuthEntry are not exposed.

hope you can help, as otherwise this is a bit of a showstopper.  i've tried to have asyncAuthPrompt send an onAuthAvailable, if there is saved authInfo, to avoid multiple prompts, but the server (twitter at least) doesn't like that after a few repeats and shuts down the account.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Priority: P1 → P3

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.