- From: Jordan Chaitin <jordanchaitin@gmail.com>
- Date: Wed, 24 Jan 2018 17:10:04 +0000
- To: Thomas Broyer <t.broyer@gmail.com>
- Cc: ietf-http-auth@osafoundation.org, public-html@w3.org, whatwg@whatwg.org, ietf-http-wg@w3.org
Many thanks for the clarifications and correction. Omitting out the WWW-Authenticate header seems the most straightforward for 401s but including that header and simply sending a non-standard scheme (i.e. “cookie”) sounds like a better idea - seeing as we’d be going against the standard anyway, so might as well make it as meaningful as possible. Thanks again, Cheers > On Jan 24, 2018, at 20:50, Thomas Broyer <t.broyer@gmail.com> wrote: > > [Reposting from another mail address hopefully subscribed to more lists] > > On Wed, Jan 24, 2018 at 1:56 PM Jordan Chaitin <jordanchaitin@gmail.com> wrote: > Hi all, > > I’m a web developer looking for an appropriate http status code for situations when the user submits an invalid password. > > AFAIK, it is commonly understood that 401 is the most suitable > > Hmm… If you're talking about your login form, then I would disagree. The POST request means "validates those credentials and then create a token/session-cookie", and the appropriate response is probably more a 400 than a 401. > 401 is for the case when you try to access a protected resource and don't provide credentials (in this case, you don't have a valid "session"), so you'd be presented the login form instead: you're not authorized to use this resource (granted, one could see the POST login form to be "create a session", with the payload containing the credentials, so a 401 could be seen as OK; I do disagree though, this is far-fetched IMO). > … > > but it requires that a WWW-Authenticate header is sent back. However, this header needs to mention the authentication type and the list of valid authentication schemes (as found at http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml ) doesn’t include anything related to cookies. Google led me to a draft proposal by Thomas Broyer (https://tools.ietf.org/html/draft-broyer-http-cookie-auth) which seems to have quietly died almost a decade back. > > Yes, in practice people use a 303 to the login page when the user tries to load a protected resource. > > I do use a 401 for AJAX requests though. I simply omit the WWW-Authenticate then (which is non-compliant, but who cares?), or use a custom scheme. Neither is "ideal", but nobody seems to care enough to try to standardize anything (well, for AJAX APIs, you could use the Bearer scheme <https://tools.ietf.org/html/rfc6750> provided you're also passing a session-ID/token with an Authorization header with the Bearer scheme; the fact that it's defined in terms of OAuth 2.0 does not make OAuth 2.0 mandatory, what matters is that you have a "bearer token", granting you access only by being able to present it, with no other condition as to how you obtained it)
Received on Monday, 29 January 2018 06:13:01 UTC