61669 - Embedding Apps can't do basic auth repeatedly, due to cache [squid proxy]

Status: VERIFIED WORKSFORME

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[edburns]

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.

Comment 1

[Judson Valeski]

-> g

Comment 2

[edburns]

*** Bug 59981 has been marked as a duplicate of this bug. ***

Comment 3

[edburns]

Here's the pref to disable the cache:

user_pref("browser.cache.disk_cache_size", 0);

Comment 4

[Paul Wyskoczka]

Updating QA Contact

Comment 5

[Frank Faubert]

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?

Comment 6

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 7

[gordon]

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.

Comment 8

[Tom Mraz]

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.

Comment 9

[Darin Fisher]

basic auth works just fine for me using TestGtkEmbed.  can you please supply
a testcase for this bug?  thx!

Comment 10

[Tom Mraz]

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.

Comment 11

[Darin Fisher]

OK.. using a Netscape Proxy, I'm not having any trouble authenticating with the
testcase you provided.  Time to try squid.

Comment 12

[Darin Fisher]

-> me

Comment 13

[Darin Fisher]

OK.. once i setup a squid proxy i was able to duplicate this bug.
investigating...

Comment 14

[Darin Fisher]

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!

Comment 15

[Tom Mraz]

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.

Comment 16

[Darin Fisher]

marking WORKSFORME.

Comment 17

[David Epstein]

was able to authenticate w/ above case.