[haiku-commits] Re: haiku: hrev47935 - in src/apps/haikudepot: ui model
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 1 Oct 2014 09:54:05 +0200
On Wed, Oct 01, 2014 at 09:20:51AM +0200, Stephan Aßmus wrote:
> Am 01.10.2014 08:41, schrieb pulkomandy:
> >On Tue, Sep 30, 2014 at 10:32:55PM +0200, superstippi@xxxxxx wrote:
> >>504501a: HaikuDepot: Fixed creating/updating ratings.
> >>
> >> * The HTTP Basic authentication never worked. BHttpRequest.SetUserName()
> >> and SetPassword() have no effect at all, unless there is a
> >> BHttpAuthentication set for the given URL on the BUrlContext. This
> >> part
> >> of the services API isn't very intuitive, yet.
> >
> >This is not completely right. The BHttpAuthentication object is created
> >when a request is made and results in B_HTTP_STATUS_UNAUTHORIZED (402).
>
> Ah, ok.
>
> >In your case the URLs are accessible both with and without
> >authentication, and it would seem the 402 error never happen. does the
> >server still provide a WWW-Authenticate header? If it does, we could
> >change the BHttpRequest code to create the authentication object based
> >on that header, rather than waiting for the 402 error. But if it
> >doesn't, we can't gues which type of auth (basic or digest) is needed so
> >we can't create the object without developer interaction.
>
> Well, in my case I knew that I need to authenticate for certain requests. So
> for these, I used SetUserName() and SetPassword() on the BHttpRequest. I did
> not expect that by default, in the best of cases, this would result in *two*
> requests. I would have expected that the first request already contains the
> authentication. My expectation was that this just sets HTTP headers in the
> right form (encoding of the password). At first, I realized that I call
> SetHeaders() after setting the authentication and I thought, doh, I am
> overriding the headers instead of adding additional ones. But that was not
> the case either, I had to read all the implementation to understand what I
> am doing wrong.
>
> I think it is nice that the request pulls the authentication information
> from the context if needed. But when I set username and password manually,
> it should assume that I know what I am doing and use authentication for the
> initial request instead of waiting for it to fail in a specific way and then
> retry. If it needs the auth type, then just force it to be set in the API.
> At least default to something when username and password are specified.
We can't "guess" the authentication type. Digest authentication is
initialized by the server which sends an authentication realm and a
nonce, which is used to encrypt the password, so we can't initiate it
from the user side. Basic authentication will send the password and
login base64 encoded, which basically is the same as sending them in
clear, and we don't want this happening by accident because of a
misconfigured server or buggy software.
Hence my question: does the HaikuDepot server send the WWW-Authenticate
header? If so, the only change we need to do is remove the check for a
402 error and create the authentication object when we receive this
header. It will still need a first "dummy" request, but digest
authentication can't work otherwise.
If the server doesn't advertise the authentication feature, only basic
authentication can be used. So if we change the API to force callers to
specify an authentication type, they can either force basic and start
authenticating immediately, or force digest, and nothing will happen
until the server sends a request with the WWW-Authenticate header
starting the digest auth handshake. This opens more questions: what if
the user forces one authentication type, but the server requests the
other one in WWW-Authenticate? My understanding of the protocol is that
it's up to the server to decide the authentication type.
--
Adrien.
Other related posts:
