WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #25446, comment 8


Ignore:
Timestamp:
04/03/2014 08:39:45 PM (11 years ago)
Author:
RavanH
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #25446, comment 8

    initial v1  
    55This is what happens currently:
    66
    7 Trying to access the Dashboard (/wp-admin/) when not authenticated, the request is met with a 302 (temporary redirect) forwarding the user the the login form (/wp-login.php) which in turn responds with a 200 OK header. After submitting the form with incorrect login data, the form comes up again with a 200 OK response. After submitting the form with correct login data, the request is met with a 302 redirecting back to the Dashboard which now responds with a 200 OK, obviously.
     71. Trying to access the Dashboard (/wp-admin/) when not authenticated, the request is met with a 302 (temporary redirect) forwarding the user the the login form (/wp-login.php) which in turn responds with a 200 OK header.
     82. After submitting the form with incorrect login data, the form comes up again with a 200 OK response.
     93. After submitting the form with correct login data, the request is met with a 302 redirecting back to the Dashboard which now responds with a 200 OK, obviously.
    810
    911This is all according to logic and (in my view) there are no other suitable responses in this scenario. And thus, it does not leave much room for recognizable access log patterns to be used by security mod filters.
    … …  
    1315What if the whole WP authentication flow was changed? For example like this:
    1416
    15 Trying to access the Dashboard (/wp-admin/) when not authenticated, the request is met with a 401 response and shows a login form instead of the Dashboard. Now after submitting that form with incorrect login data, the request is again met with a 401 response (after an X number of failed logins this might be turned into a 403 by a plugin like Limit Login Attempts) presenting the form again. After submitting with correct login data, the request is met with a 200 OK and now shows the Dashboard.
     171. Trying to access the Dashboard (/wp-admin/) when not authenticated, the request is met with a 401 response and shows a login form instead of the Dashboard.
     182. Now after submitting that form with incorrect login data, the request is again met with a 401 response (after an X number of failed logins this might be turned into a 403 by a plugin like Limit Login Attempts) presenting the form again.
     193. After submitting with correct login data, the request is met with a 200 OK and now shows the Dashboard.
    1620
    1721In this scenario, there are no redirects and the request URL does not change. Less confusing and allows different response headers according to different visitor credentials like auth cookies, session or POST data. And now there would be recognizable patterns in the access log for sec filters :)