After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583462 - emits authenticate twice in specific conditions
emits authenticate twice in specific conditions
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
2.25.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2009-05-21 15:35 UTC by Gustavo Noronha (kov)
Modified: 2009-05-21 21:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case for the problem (2.70 KB, patch)
2009-05-21 17:48 UTC, Gustavo Noronha (kov)
none Details | Review

Description Gustavo Noronha (kov) 2009-05-21 15:35:56 UTC
This is that bug we have in WebKitGTK+, where the auth dialog shows up twice, after you cancelled it once (https://bugs.webkit.org/show_bug.cgi?id=24818). I have been investigating it, and I think I am close to understanding it.

The problem is, when no authentication is atempted (the dialog is cancelled), soup adds the auth to its host->auths hash table nevertheless, even though it has no username/password. When soup-auth-manager's request_started is called, lookup_auth succeeds; since the last "auth" did not fail, it emits the authenticate signal to fill up the auth data, but also gets a 401, and emits authenticate again when it gets got-headers.

I am trying to hack auth-test.c to test this possibility, but it is hanging for me. I'll try to get a test going tonight.
Comment 1 Gustavo Noronha (kov) 2009-05-21 17:48:20 UTC
Created attachment 135131 [details] [review]
test case for the problem

There you go. This is what happens.
Comment 2 Dan Winship 2009-05-21 21:48:39 UTC
Fixed in git. Thanks for the regression test.

As this has just missed 2.26.2, you'll probably want to work around it in WebKit. You should be able to just check msg->status_code in your authenticate handler, and if it's 0, just return immediately without doing anything else. That will basically replicate the behavior of the SoupAuthManager changes. (But put a comment there noting that it can go away later once WebKit depends on a libsoup newer than 2.26.2.)