GNOME Bugzilla – Bug 786147
No proxy information in case of proxy with HTTP auth
Last modified: 2018-09-21 16:32:12 UTC
The authenticate signal is emitted when the proxy requires creadentials, but the SoupMessage and the SoupAuth passed to the signal contain the uri and host of the original request, not the proxy one. This means that, for example WebKitGTK shows the HTTP auth dialog claiming that the URL foo is password protected, when that's not true, because it's the proxy the one using HTTP auth not the request URL. Maybe we could extend SoupAuth to return proxy information, or fix it to use the proxy host and also add soup_auth_get_port()
Created attachment 357404 [details] [review] WIP This is a WIP patch just to get feedback, if this approach is ok I'll finish it.
With my limited understanding of this, considering that soup_auth_is_for_proxy() is documented as "Tests whether or not auth is associated with a proxy server rather than an "origin" server.", the fact that the getters SoupAuth are all for the "origin" server regardless of the purpose of SoupAuth is a bit misleading. I don't think changing it to return the proxy info instead would be a good idea at this point, though, as that would break the current behavior. Extending SoupAuth, as in your patch, to allow checking the proxy seems like a better approach to me.
This looks promising as i encounter this issue myself at the moment. The patch could (with some changes) also be used for gss-negotiate where the proxy uri information is missing. See: https://bugzilla.gnome.org/show_bug.cgi?id=601031
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/105.