Created attachment 232354 [details] [review]
soup-message: expose auth/proxy-auth

Add SoupMessage:auth and :proxy-auth properties, make the
corresponding getters and setters public, so that callers can force
their own authentication in some cases.

So for the purposes of WebKit, we need to preload the authentication without knowing the authentication type (or realm). In fact, it'd be useful to have an API that said something like, "Don't send any authentication with this request, but if, by chance, we are asked for authentication, respond with this username/password pair."

In reality, all that we are trying to do is to disable the internal libsoup session storage for a particular request.

I'm not sure that I understand this bit of the documentation from the new "auth" property on SoupMessage: 

 * Note that the #SoupSession will overwrite this before
 * sending the message if it believes that a different
* #SoupAuth is the correct one to be using.

In what cases does SoupSession overwrite the SoupAuth?

(In reply to comment #2)
> So for the purposes of WebKit, we need to preload the authentication without
> knowing the authentication type (or realm).

Hm... well, the realm isn't actually relevant in Basic, so you could just put in a fake realm and it would work just the same.

As for not knowing the authentication type: it's Basic. It just is. :)

> In fact, it'd be useful to have an
> API that said something like, "Don't send any authentication with this request,
> but if, by chance, we are asked for authentication, respond with this
> username/password pair."

That's what the authenticate signal is for...

> In reality, all that we are trying to do is to disable the internal libsoup
> session storage for a particular request.

So maybe a SoupMessageFlag would be better.

> In what cases does SoupSession overwrite the SoupAuth?

Whenever it has a stored auth for that URI.

(In reply to comment #3)

> As for not knowing the authentication type: it's Basic. It just is. :)

I didn't realize that digest authentication was so uncommon.

> So maybe a SoupMessageFlag would be better.

Yes, that could work too.  Once we get the authenticate signal we could reply with the credentials that we were given. This is actually similar to how the Mac port works, I think.

> > In what cases does SoupSession overwrite the SoupAuth?
> Whenever it has a stored auth for that URI.

Hrm. I don't really understand how your test works then, since the second test sends the incorrect credentials initially.

(In reply to comment #4)
> Hrm. I don't really understand how your test works then, since the second test
> sends the incorrect credentials initially.

Hm. Now that you point that out, I don't understand how that test works either.


Anyway... although I haven't really investigated CredentialStorage, it seems that it's basically the same thing as SoupAuthManager, and that really, the fix here is that we should just disable SoupAuthManager entirely, and let CredentialStorage handle everything. The only issue with this is that it means you won't get the authenticate signal any more, but we could rework authentication so that ResourceHandleSoup just gets back a 401 status and then deals with sending a new request itself, rather than expecting that to happen from within libsoup.

(Or, alternatively, ResourceHandleSoup could check the status from a got-headers handler, and then call soup_session_requeue_message() itself if it has auth, which is all that SoupAuthManager does. However, letting it fail and then redoing it matches how the new redirection code I was working on works.)

You can hackily disable SoupAuthManager by doing:

soup_session_remove_feature_by_type (session, g_type_from_name ("SoupAuthManager"))

but we really ought to expose SOUP_TYPE_AUTH_MANAGER...

Martin, this can be closed as OBSOLETE, right? WebKit does not currently need anything from libsoup on the HTTP auth front?

Yes, I believe we work around most issues we had by placing the credentials into the URL when triggering the request.

Oh right. But that's absolutely awful, so I should come up with something better still

Is there any libsoup progress here?

It seems that WebKit test http/tests/xmlhttprequest/cross-origin-authorization.html is one remaining issue.

WebKit URL passing strategy does not seem to cover this particular case:
- A first XHR same-origin authenticated request is sent (probably setting soup session internal credentials).
- A second XHR cross-origin unauthenticated request is sent (probably reusing soup session internal credentials).

The patch doesn't quite apply any more, but I pushed a rebase to wip/auth. You could try porting WebKit to use it.

Another possibility that didn't exist when this bug was filed is soup_auth_manager_use_auth().

I think this is obsolete and no longer relevant, closing. Feel free to reopen if I'm wrong.