[wp-trac] [WordPress Trac] #25446: Return HTTP status code 401 upon failed login

WordPress Trac noreply at wordpress.org
Sun Jan 19 03:02:59 UTC 2014


#25446: Return HTTP status code 401 upon failed login
-------------------------+------------------------------
 Reporter:  raoulbhatia  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  3.6
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by dd32):

 The HTTP response spec was never really designed for Web-login forms,
 assuming everyone would want to use the HTTP Authentication spec instead,
 as such it defines:
  '''401 Unauthorized'''- The request requires user authentication. The
 response MUST include a WWW-Authenticate header field (section 14.47)
 containing a challenge applicable to the requested resource. '''The client
 MAY repeat the request with a suitable Authorization header field'''
 (section 14.8). If the request already included Authorization credentials,
 then the 401 response indicates that authorization has been refused for
 those credentials.
  '''403 Forbidden''' - The server understood the request, but is refusing
 to fulfill it. '''Authorization will not help and the request SHOULD NOT
 be repeated.'''

 so technically 403 is invalid for authentication purposes - however, if
 you read "Authorization" as the HTTP Authorization spec, then it could be
 seen as allowed for a web form (Don't retry this request with that POST
 data.. that combination is forbidden), but then "refusing to fulfill it"
 doesn't apply either, as WordPress is fulfilling the request just denying
 the authentication.. which is why a 200 response is completely valid here.

 I believe the XML-RPC spec even specifies all responses must be 200 OK
 (with an error object in the response) too.

 That being said, the web has moved far from the origins of the HTTP specs,
 and I'm OK with returning a 403 here, assuming it doesn't break anything.

 One thing that needs to be kept in mind: Certain browsers *cough*IE*cough*
 do the whole "smart HTTP error" messages where they don't display the
 server output, but rather their user-friendly output. I'm not sure what
 browsers/versions would be affected here, but it's worth mentioning.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/25446#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list