Question: RFC 7235 authentication

[pfeatherstone]

I'm trying to implement basic authentication but struggling a bit.

I'm implementing

For the initial 401 response i'm using

using http_request  = boost::beast::http::request<boost::beast::http::string_body>;

auto http_unauthorized (const http_request& req)
{
    http::response<http::empty_body> res{http::status::unauthorized, req.version()};
    res.set(http::field::server, BOOST_BEAST_VERSION_STRING);
    res.set(http::field::www_authenticate, "Basic realm: \"Access to the staging site\"");
    res.keep_alive(req.keep_alive());
    res.prepare_payload();
    return res;
}

The authorization request i get back from the browser is correct and I can decode the base64 encoded username and password. So that's all good.

I then reply with 200 response using:

auto http_ok_status (const http_request& req)
{
    http::response<http::empty_body> res{http::status::ok, req.version()};
    res.set(http::field::server, BOOST_BEAST_VERSION_STRING);
    res.keep_alive(req.keep_alive());
    res.prepare_payload();
    return res;
}

However what follows is one of two behaviours:

• the browser doesn't resend the original request and the page doesn't load
• or it does but uses multiple TCP connections for HTTP requests which all need to be authenticated again, so I'm having to input username and password for every javascript and CSS file it wants to load.

Does that make sense? I'm forwarding the keep_alive requests everywhere trying to avoid multiple TCP connections.

Has anybody got authentication working reliably with Beast ?

[pfeatherstone]

Also I noticed that if i don't use res.prepare_payload(); in http_unauthorized() the full response doesn't make its way to the browser correctly. Though in principle, I don't know why i need to call prepare_payload() on http::empty_body since by definition there is no payload...

So do i have other similar bugs where full HTTP responses aren't making their way to the browser. Maybe there is chunked encoding somewhere. I don't know.

[ashtum]

However what follows is one of two behaviours:

• the browser doesn't resend the original request and the page doesn't load
• or it does but uses multiple TCP connections for HTTP requests which all need to be authenticated again, so I'm having to input username and password for every javascript and CSS file it wants to load.

The flow you're using seems incorrect. The browser is free to open a new connection whenever it wants. Does your server logic rely on the assumption that the second request will be sent using the same connection? You might consider using cookies for session management to map subsequent requests to the same state stored on the server side.

Also I noticed that if i don't use res.prepare_payload(); in http_unauthorized() the full response doesn't make its way to the browser correctly. Though in principle, I don't know why i need to call prepare_payload() on http::empty_body since by definition there is no payload...

So do i have other similar bugs where full HTTP responses aren't making their way to the browser. Maybe there is chunked encoding somewhere. I don't know.

401 Unauthorized responses can include a body. If you omit the call to prepare_payload, the serialized message will not include a Content-Length header, causing the client to rely on an end-of-stream error to determine the end of the message.
https://datatracker.ietf.org/doc/html/rfc2616#section-4.4

1.Any response message which "MUST NOT" include a message-body (such
as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in
the message.