I am implementing the authentication for an app, and I am using a pluggable system with \"authentication methods\". This allows me to implement both HTTP Basic as well as HT
What about this one ?
When requesting the login form which is a public page, you get what you want, so it's a 200 status code :
GET /login -> 200
When requesting for a page that needs a http level authentication that you didn't initiated (basic http, ssl certificate, etc.), the application must tell the browser itself that it needs to initiate this authentication for you :
GET /secured -> 401 with WWW-Authenticate header
When the authentication is a cookie-based session, you already have a cookie (if it's not the case, you will get one with the set-cookie header when requesting the page) but this cookie doesn't tell that you are allowed to access the /secured uri. So if you try to access this uri, you should get a "403 forbidden" status. Then the "log in" action is no more than just changing the state of the application with a POST request to make the application grant access for this cookie, so...
Log in with bad credentials:
GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 403 with HTML login form, displaying errors
Log in with good credentials but not enough permissions :
GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 403 with HTML page saying "I know you are John, but you can't get this page"
Log in with good credentials and enough permissions :
GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 302 (temporary redirection to /secured)
GET /secured -> 200