Hello, My embedding app implements nsIPrompt to allow the user to provide username and password data on a URL fetch. If your disk cache is clear, and you visit a url with basic auth, it works fine. However, if, at a later session, you visit the same URL, it will not work. Disabling the cache prevents this problem. Please re-assign to the cache person.
*** Bug 59981 has been marked as a duplicate of this bug. ***
Here's the pref to disable the cache: user_pref("browser.cache.disk_cache_size", 0);
Updating QA Contact
This bug seems pretty major, and blocks bug #60304 which is also pretty major. Any chance of getting this escalated -- or at least set to a specific milestone?
Correction: Changing QA contact for the Embed API bugs to David Epstein.
Ed, is this still a problem with the lastest builds. We have a new cache and we've cleaned up the HTTP validation code quite a bit.
It doesn't authenticate at all to me. When I use the TestGtkEmbed and the authentication dialog appears I can fill in any name/password value (even the correct one) but the authenticated page never appears only the dialog reappears again and again. Only the Cancel button works fine -> the authentication error page appears.
basic auth works just fine for me using TestGtkEmbed. can you please supply a testcase for this bug? thx!
You can try this URL: http://poli.feld.cvut.cz/~mraz/tmp/ User: josef Password: nechvil I'm using a squid proxy to connect to Internet (I have no other possibility). I've retested it with my own trunk build from 2001-06-12 and it still doesn't work.
OK.. using a Netscape Proxy, I'm not having any trouble authenticating with the testcase you provided. Time to try squid.
OK.. once i setup a squid proxy i was able to duplicate this bug. investigating...
oops... i take that back... it seems to work just fine for me. i previously mistyped the password :P so, i'm not sure how to reproduce this bug. Tom: could you get a packet trace? (using a tool like ngrep -- http://ngrep.sourceforge.net), and if you have a debug build could you try getting a HTTP log by setting the NSPR_LOG_MODULES=nsHttp:5 and NSPR_LOG_FILE=log environment variables? if you could generate either of these it would greatly help in tracking down the cause of this problem. thanks!
So I've made more tests and it seems that with the M0.9.1 it doesn't work at all no matter when using/not using proxy. But I've made fresh trunk checkout and recompiled it and it is FIXED now! So it could be probably resolved as WFM.
was able to authenticate w/ above case.