[haiku-commits] Re: haiku: hrev47935 - in src/apps/haikudepot: ui model
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 01 Oct 2014 10:26:21 +0200
Hi,
Am 01.10.2014 09:54, schrieb pulkomandy:
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.
The server is only ever contacted by HTTPS, so the connection is
encrypted. There is an increased risk by sending the username and
password with each request. However, there is a need to send it at least
once. The server supports another method of authentication which is
token based and requires sending the password only once. For simplicity,
I have opted to implement the HTTP BASIC authentication at first.
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.
Well, the server needs authentication only for certain requests. It only
knows the type of request after parsing the JSON that the client has
sent. So without having much of a clue, I would say the server does
/not/ send a WWW-Authenticate header.
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.
To make the API more intuitive, /something/ has to be changed about it
IMHO. Even just a command line error would have helped me, or a comment
in the header. But silently doing nothing was not helpful.
Best regards,
-Stephan
Other related posts:
