Add WWW-Authenticate header for 401 response

[vanHoesel]

response_403 says "Unauthorized"

It must be: 401: Unauthorized 403: Forbidden

The whole list can be found at: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes for those that hate RFCs.

Since back in the '90s the were not so strict in using 'authorise' and 'authenticate' and messed it up...

It could had been: 401: Unauthenticated 403: Forbidden

a 401 should be provided with a "WWW-Authenticate" header as well

[racke]

IMHO 401 should NOT result in a "WWW-Authenticate". Really annoying if you get a popup as user and you can enter anything without a chance to get ever authenticated.

[vanHoesel]

I don't care if you do not like it but the RFCs say you MUST:

«The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.»

see: http://tools.ietf.org/html/rfc7235#section-3.1

In most html-web-surfing situations, you would not return a 401 anyways, you will het rerouted to a "/login" page with a 3xx status code.

[racke]

On 10/27/2014 04:13 PM, Theo van Hoesel wrote:

I don't care if you do not like it but the RFCs say you MUST:

«The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.»

see: http://tools.ietf.org/html/rfc7235#section-3.1

In most html-web-surfing situations, you would not return a 401 anyways, you will het rerouted to a logion page with a 3xx status code.

— Reply to this email directly or view it on GitHub https://github.com/PerlDancer/Dancer2/issues/732#issuecomment-60608962.

So why would you annoy user because the developer throws 401? It doesn't make sense. If the developer doesn't use the proper code, it is his fault not Dancer's. You can put add that RFC requirement in the docs.

Regards Racke

Modern Perl, Dancer and eCommerce consulting.

[xsawyerx]

We fixed the status name.

We should follow the RFC and add the right header. I'd like to see a separate issue for that though.

[vanHoesel]

Adding the right header will be quite some challenge... It means you then also need to know how the client/surfer needs to Authenticate itself. But I will leave that up to you guys, there seems not to be too much enthusiasm in using WWW-Authenticate in the usual web applications.

[racke]

Using WWW-Authenticate is a disruption for the user.

[xsawyerx]

@racke it's the RFC, whether we like it or not.

[vanHoesel]

@racke , ues, it might be disrupting what some think is te 'normal' flow, but think about it... the normal flow for web-applications is to route the user to a /login page with a hidden parameter that contains the original location. You do not use a 401 status in those cases. No worries

[racke]

Yeah, but a typical error is to use 401 for the case that the user is authorized, but lacks permission for a specific link.

I recommend to make sure to clearly document this and put out a warning on the users list.

Maybe also a "dont_care_about_rfc" option.

[racke]

In fact, Dancer::Plugin::Auth::Extensible and Dancer2::Plugin::Auth::Extensible are using 401 in one specific case.

[vanHoesel]

@racke «a typical error is to use 401 for the case that the user is authorized, but lacks permission for a specific link» .... THAT is a typical 403, FORBIDDEN

please do not make the confusion the original authors made... it should have been:

401 Unauthenticated

So, once you're in, being authenticated, you can end up at resources or webpages that you do not have sufficient access rights to, being unauthorised, you are FORBIDDEN to go there.

[racke]

I know now, but you will find that in many Dancer applications. You can't really break them without being careful.

[vanHoesel]

I hope not that many Dancer applications follow that design, for then I do hope that the browsers are way smarter and will have to cleanup the shit.

If I understand the way DPAE and relatives handle it now, this is what is actually being returned:

HTTP/1.1 401
Server: DancerX
Content-type: text/html

<HTML>
    ...
</HTML>

Now lets just hope that the missing "WWW-Authenticate" and the presence of valid html might fool the browser, and simply render the page.

But that behaviour is not what we het when doing some LWP stuff:

if ($response->is_success) {
     print $response->decoded_content;  # or whatever
 }
 else {
     die $response->status_line;
 }

I'd love to 'see' a demo of a D2PAE that does return a 401

[xsawyerx]

We should return a 401, document it clearly, and submit requests to plugins that in their newer (fixed) versions (if any fixing is needed), it will rely on the latest Dancer2 which adds the WWW-Authenticate header.

I'd be surprised about such broken behavior in applications that rely on 401 which doesn't initiate an authorization. That's like relying on a redirect providing content.

[xsawyerx]

I edited the issue title to correspond to the current topic.

[rleir]

When the app returns a 401 the RFC intent was that the WWW-Authenticate header would contain a 'challenge' usually specifying a domain for authentication. That makes sense for basic or digest auth. But what if the app is doing OAuth or something with JWT's? Dancer does not know that, so it does not know what to put in the header. In my mind the responsibility is with the app developer to set that header, with whatever domain or whatever. Then return the 401 as needed. It may be that the correct action is for the app to redirect to a login form. @racke I agree.

This issue looks to be stale, would you close it when you get a moment please?

[vanHoesel]

Once more: http://tools.ietf.org/html/rfc7235#section-3.1...

401 (Unauthorized) MUST send a WWW-Authenticate header field...

The original issue however had nothing to do with sending the headers, it was a wrong naming for the 403 status... Forbidden

and resumé... if one does dancer login pages with a redirect to /login - that page is supposed to be with 200 (OK), it's just a normal web-page request/response. And one could login with OAuth and so on.

Using dancer as an API, is a whole different thing - and i leave it up to the ones that implement any of the plugins... it is typically the client that does not know how to handle the OAuth responses from a server that sends off a 401.

time to rethink my own Dancer2::Plugins.