The module does not always send basic authentication headers (WWW-Authenticate / 401) when no authentication details are sent initially.
This causes some browsers to issue a security warning when attempting to visit a basic-auth URL:
http://user:pass@example.com/endpoint/
Changing this would provide the standard browser basic-auth login box if the credentials are not provided in the URL.
If there are no basic authentication details sent and authentication is required by the resource handler, ensure services correctly sends WWW-Authenticate / 401 headers, i.e.
header('WWW-Authenticate: Basic realm="Services Basic Authentication"');
header('HTTP/1.0 401 Unauthorized');
exit;
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | services_basic_auth-401-status-code-2444399-4.patch | 868 bytes | markpavlitski |
Comments
Comment #1
xen commentedIt should do, it was implemented 2 years ago. But apparently services has changed.
Comment #2
xen commentedOK, after further investigation, it works as it should.
The WWW-Authenticate header and the 401 code is returned if the resource properly throws an 401 error.
However, it's up to the resource handler how it deals with calls to index. The standard node resource allows access if the user (which would be anonymous for the first request) has the "access content" content permission. Whlie commerce_services' order resource simply lists the orders which the user has access to (which would be none in any sane configuration).
Requesting a specific order from commerce_services gives a 401 with the proper WWW-Authenticate header. And supplying the right Authorization header causes the index method to return the orders the given user has access to.
So I'm closing this issue.
Comment #3
markpavlitski commentedThanks for the investigation @Xen!
I'm still intending to put some time into this, as there are definitely edge cases where the resource handlers don't trigger this correctly.
It might be that the issues get pushed out elsewhere but I'll leave this open as a placeholder until I've had a chance to dig into it further.
Comment #4
markpavlitski commentedOK, so after some further investigation it looks like newer versions of Services module triggers this issue because of the change in issue #2158563: Services should return a 403 instead of a 401 for access denied.
In essence, services used to return a 401 status code when authentication failed (which was picked up in
services_basic_auth_rest_server_execute_errors_alter) but now it returns a 403 status code and expects auth providers to modify as required.From that services issue:
Comment #5
markpavlitski commentedComment #7
markpavlitski commented