If someone tries to visit an internal page which is only accessible once they have logged in, what error code should be returned? 403 doesn't seem right, because they have not authenticated. However, 401 doesn't work either, because that implies they can log in using basic auth, which we are not using.
Is it correct, when authentication is done via a method other than WWW-Authenticate headers, to use 403 in place of 401? If not, what code should be used?
Note: I have found some similar questions to this, but they all seem to be asking about sites using http basic auth, rather than any other authentication method.
The status code 401 does not imply you support basic authentication. It means that the server would not serve the request because appropriate credentials were missing.
The server can send back a WWW-Authenticate header to indicate what types of credentials it supports. If you only support JWT tokens for example, you would send back 'bearer'.
Related
What http code should i respond with if I cannot find a user in the database and therefore, cannot authenticate him.
I personally do not like like idea of returning 404.
I would recommend either 401 or 403 .404 is not found which could be also because resource is not available even user is authenticated. Ref Standard Error Code
401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
When a user is unauthorised to access a page, I send a HTTP 401. Additionally, as required by the HTTP/1.1 spec, I also send a WWW-Authenticate header.
I know of at least 1 case where omitting this header causes an issue: Firebug (the Net tab will be empty).
A user can log in with both an email address or a username, and a password. The form is submitted over AJAX, and a JSON response takes care of redirecting the user after successfully logging in, or displaying an error message on failure.
On Windows Phone 8, a custom dialogue is shown when this header is present. It has fields for User name, Password, and Domain. It also has checkboxes for Show password and Remember my password.
The thing is, this dialogue doesn't work at all with the authentication process of the application.
The value of the header doesn't seem to matter, I've tried with WWW-Authenticate: form and WWW-Authenticate: blah but I get the dialogue regardless. How can I suppress this while still adhering to the spec?
From your question and the comments it seems you are doing form-based authentication, but, in order to comply with the HTTP spec, you thought you should return a 401, and, as that requires to also send the WWW-Authenticate header, you added that as well.
The fact of the matter is: Form-based authentication is non-standard, and you should not use 401 Unauthorized, which is to be used with standard HTTP authentication. So using a dummy authentication method might help you comply with the letter of the spec in terms of WWW-Authenticate, but you shouldn't be using 401 in the first place.
The spec reads:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field.
All this talk about HTTP headers (WWW-Authenticate and Authorization) makes it clear that this is about giving the client software the information needed to do the standard HTTP authentication (via a dialog in most cases).
Btw providing a custom authentication method in the WWW-Authenticate header makes sense when you want to to HTTP authentication, i.e. via the Authorization header, but use your own authentication scheme, rather than basic or digest. This of course requires a client that understands that custom scheme.
So what could you do instead? As form-authentication is non-standard, this is not defined in the specs, but how about redirecting the user to a/the page with the login form using a 307 Temporary Redirect, perhaps adding information so you can automatically redirect the user back to the page he wanted to access after verifying the credentials.
I found a strange thing when i'm coding a net-spider to a specific website.
I used fiddler and chrome(as well as other web-browsers) to log-in a website(HTTP, not https) and get all package(as well as the cookie) that sent and received:(
first package 'Get' to request the log-in page and the cookie, then use the cookie received to request verification code and some other pics. and then send login request with userid, password and verification code to server and server response with correct info)
Then I log-out and Clear all Cache and Cookie and use Fiddler to Relay(Simulate) the whole process (Since I know all packages' format that i should send): request the log-in page to get cookie, use the cookie to request all pics( auth code image included), and then use the cookie and auth code to request login(userid and password are correct)...but failed.
I'm sure the failure is not caused by invalid userid or password or auth code, and i believe there is nothing special on the front-end(html,script are checked), but it puzzled me a lot how can the server tell i used browser or not in back-end..
I'm not request anybody to solve the specific problem. i'm just wanna know DOES ANYONE HAS HAD SIMILAR PROBLEM i described?
the specific website is not important and i must say the whole practice is completely harmless! i'm not doing any hacking stuff, on the contrary it will help some people.
======================================================
I've finally figured out the reason: the log-in page has a hidden input() and i carelessly overlooked that since its value looks almost the same every time. Web server can not detect replayed log-in attempts if we simulated all necessary HTTP request packages.
Thank you guys~
Servers cannot magically tell whether they're talking to Fiddler or not.
If Fiddler and your client are sending the exact same requests, that means that the server in question is using a "one time token" (sometimes called a nonce) in its login form. If the server ever sees the same token again, it rejects the logon. Sometimes the nonce isn't sent directly, and is instead used in the computation of a "challenge-response" as occurs in authentication protocols like NTLM. In other cases, the nonce is a CAPTCHA, which helps prevent you from using a bot to automatically log in to a site like this.
Unless you can share more details of the target site (or a SAZ file of the login process), it's unlikely that folks will be able to help you.
I'm just reading Paypal's API documentation, e.g. Adaptive Accounts API
My question: What's the reason/advantage of using (custom?) HTTP Request Headers for authentication instead of "normal" POST/GET (or even COOKIE) variables?
In the mentioned example PayPal uses the following HTTP Request Headers:
X-PAYPAL-SECURITY-USERID
X-PAYPAL-SECURITY-PASSWORD
X-PAYPAL-SECURITY-SIGNATURE
X-PAYPAL-APPLICATION-ID
X-PAYPAL-DEVICE-IPADDRESS
X-PAYPAL-REQUEST-DATA-FORMAT
Why use HTTP headers rather than something in the body of the request?
By keeping your authentication info separate from the payload (the data you are transmitting) you make it easier to handle authentication at an earlier stage in the request pipeline. For example, a gatekeeper server can receive requests and authenticate them by looking only at the headers, and then pass them along to the module/server/class that does parses the request body and does the real work.
If the request fails authentication, it can be rejected before it even gets near the code that deals with the money.
Of course, you can architect your system this way no matter what, but keeping it in the headers means you don't need to parse the request body or even look at it. You also don't need to worry about adjusting Content-Length: if you wanted to modify the headers before passing it along to another server.
Why use custom HTTP headers rather than WWW-Authenticate or Cookie?
I think this is simply because PayPal wants a more robust scheme than either of these can accommodate. WWW-Authenticate only allows for basic (cleartext) and digest (MD5) authentication, and many better schemes have been developed since the spec for these was written. They also don't allow for more than a username and password.
Cookies are technically opaque bits of data that you receive from a server and pass back to it unchanged. Again, they could tell you how to generate the info that you pass along in a Cookie header, but that wouldn't really be following the spec, so at that point, why not just use some custom headers?
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication", look here.
User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
If the connection is trusted between two parties and SSL is implemented, HTTP Authentication is a simple to implement way to authenticate between two fixed parties. The connection is simply rejected at the traffic level if the authentication fails.
I don't think Paypal uses HTTP Authentication for payments? It's just for you to access API features to build your own admin interface for Paypal accounts?
The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.