New password is not used for WebDAV after successful authentication

[aurimasv]

After successfully authenticating with a WebDAV server, changing the password to an incorrect one still manages to "Verify Server" and sync files.

Debug log shows that the wrong password is being used, but a 200 response is still received

(3)(+0000007): HTTP OPTIONS for https://myEmail:wrongPassword@www.box.net/dav/test/zotero/

(3)(+0000397): Server: nginx
Date: Sun, 10 Feb 2013 09:24:01 GMT
Content-Type: httpd/unix-directory
Connection: keep-alive
X-Robots-Tag: noindex, nofollow
DAV: 1,2
Allow: GET, PUT, DELETE, MKCOL, OPTIONS, COPY, MOVE, PROPFIND, PROPPATCH, LOCK, UNLOCK, HEAD
MS-Author-Via: DAV
Content-Length: 0


(3)(+0000000): 

(3)(+0000000): ===>200<===(number)

Turns out that this is a problem with basic auth being cached quite aggressively (LiveHTTPHeaders shows the Authorization header corresponding to the correct password being sent even when the wrong password is entered in the URI). I found a couple bugs on bugzilla that are in the ballpark of this issue (there are many more): https://bugzilla.mozilla.org/show_bug.cgi?id=55181 https://bugzilla.mozilla.org/show_bug.cgi?id=260839

Basically, I think we might need to use nsIHttpAuthManager:clearAllI() or :setAuthIdentity() http://dxr.mozilla.org/mozilla-central/netwerk/protocol/http/nsIHttpAuthManager.idl.html Probably when password is changed.

var authenticationManager = Components.classes["@mozilla.org/network/http-auth-manager;1"].getService(Components.interfaces.nsIHttpAuthManager); 
    authenticationManager.clearAll();

I added the above to unverifyStorageServer and it did solve the problem, but I don't think this is what we want to do. I believe this would clear all authentication globally. Also, even using setAuthIdentity would mess with user authentication in the browser itself. So, say, if a user is logged in using basic auth on the webDAV server in the browser, and then he goes to enter the username and password in Zotero (FF plugin), he would be logged out of the site in the browser. I don't think this is something we would want to do, although it seems to be a pretty rare case.

This does not appear to affect username changes.

[dstillman]

I'm OK with using setAuthIdentity() here. I think using WebDAV in a browser is sufficiently rare that we don't need to worry about it. Even if you were logged in (which you're probably not, because if anything you're probably using a cloud storage service with a cookie-based front-end), you'd just get an unexpected basic auth prompt and have to type in your credentials again. And we only need to do it if a different password was cached previously.

[aurimasv]

Ok, nvm what I said above about setAuthIdentity. I don't think this will work unless we can also supply the correct "realm", which we can't know until the server responds. Also I think the proper way is to use nsIHttpAuthCache::ClearAuthEntry (http://dxr.mozilla.org/mozilla-central/netwerk/protocol/http/nsHttpAuthCache.cpp.html#l175), but that also requires "realm". So I don't think we can currently address this without clearing the whole cache like in the code above.

For reference, this bug report was somewhat informative (comment 17 and the patch that it's discussing) https://bugzilla.mozilla.org/show_bug.cgi?id=143575#c17