Re: http-client egg and authentication

[Peter Bex]

On Mon, Sep 26, 2022 at 12:15:10AM +0200, Christian Himpe wrote:
> Dear All,
> 
> so I found this recent StackOverflow issue: 
> https://stackoverflow.com/questions/72904388/how-do-i-use-http-basic-auth-with-http-client
>  based on which I tried to use `make-uri` and pass the URI record (including 
> credentials) to the http-client. This also gives a 403 reply from the server. 
> I also tried manually encoding `"myuser:mypass"` as base64 without use.

Hi there,

I had a look since I didn't really remember and couldn't get it to work
either.  But after some re-reading of RFC2617, it made sense to me:

Normally, a server should respond with 401 Unauthorized and a
WWW-Authenticate header containing the acceptable authentication types,
and, in case of digest authentication, a challenge.

Given a username and password, http-client can't really (in general)
simply send a basic auth header to the server.  This would be needlessly
insecure in case the server accepts (only) digest auth.  And of course,
sending a digest auth header is impossible since it requires receiving
a challenge nonce first.

So I guess you're (somewhat) out of luck, if your server doesn't
correctly respond with a 401 response on the initial request, you
can't rely on the builtin authentication mechanism.

Instead, you'd have to pass in an intarweb request object instead of an
URI, and construct the Authorization header yourself.

> As a sidenote, using `uri-common`, I was not able to get a slash between port 
> and path from `make-uri`; I had to use `(update-uri (uri-reference ...) ...)`.

You probably forgot to use a list with a slash symbol at the start.
That makes a path absolute.  '(/ "foo" "bar") is /foo/bar, whereas
'("foo" "bar") is foo/bar.  It's a bit awkward, but that's how it works.

Cheers,
Peter

signature.asc
Description: PGP signature