2

We have some rules for a subtree of Locations, which involve Require-ing ldap-group and exprs.

The user is duly challenged to supply login-credentials, which are verified.

However, even when the credentials are correct and the access is denied due to other reasons (such as belonging to a wrong group or coming from an incorrect IP-address), the server's response is always 401 -- instead of 403.

As a result, the browsers keep prompting users to "try again"... Can I tell Apache (2.4) to use 403, if the information supplied in the Authorization-header checks-out, and it is some other rule, that rejects the request?

Improve this question
7
  • I get your point. Believe me. It appears based upon your description that a 401 is correct. I would be focusing on why the authorization process is failing or not handled another way. For example, if a user gets a 401, you can present a custom 401 with a login prompt and/or a support phone number. From there, you can possibly look at why the user cannot access the resource. If it is a group issue, then that should be easy to fix. If it is IP based, then that is a policy issue that is also easy to fix. I would be working on these things and using a 401 error to capture the issue for good UX.
    – closetnoc
    Commented Dec 8, 2016 at 22:21
  • It's not just the HTTP status code you would need to override but the entire response... WWW-Authenticate HTTP response headers etc. (I would think... that in order to override this you would need to manually handle the authorization in your server-side script rather than rely on Apache to do it? Don't know.)
    – MrWhite
    Commented Dec 8, 2016 at 22:25
  • @closetnoc Maybe I got it wrong, but I didn't think the OP's problem was "why" it was failing. But being able to change the response (under certain conditions) when it does... the user might be a valid user (the username and password are correct), but they just don't belong to the correct group or something? If the user is prompted for login credentials again (a 401 - the default) then they might just assume they entered their password wrong?
    – MrWhite
    Commented Dec 8, 2016 at 22:32
  • @w3dk That is why the custom 401. I get what the OP is asking. I am just taking another tack. I am suggesting using the 401 to capture the user and convert it to an opportunity to properly fix the problem. IE, "If you get here, something went wrong that we may need to fix on our end. Please call us and let's see what went wrong so we can fix it properly." Changing it to a 403 may still be confusing the user and not actually getting to the root of the problem. Just a different thought. Cheers Mate!!
    – closetnoc
    Commented Dec 8, 2016 at 22:37
  • @closetnoc Yes, I did wonder about a custom 401 - but didn't think it would be triggered in such circumstances? If it is then that would certainly be the way to go. And yes, I'm not convinced a 403 would be user friendly either (although I was trying to bend my mindset)... what if the "correct" user wants to login? Do they have to reload the page? Or logout (because they did authenticate, but where just not authorized) then reload the page?
    – MrWhite
    Commented Dec 8, 2016 at 22:52

1 Answer 1

Reset to default
2

(Posting a copy of my answer on Server Fault, per OP's request.)

I think what you want is AuthzSendForbiddenOnFailure:

AuthzSendForbiddenOnFailure On

Context: directory, .htaccess

If authentication succeeds but authorization fails, Apache HTTPD will respond with an HTTP response code of '401 UNAUTHORIZED' by default. This usually causes browsers to display the password dialogue to the user again, which is not wanted in all situations. AuthzSendForbiddenOnFailure allows to change the response code to '403 FORBIDDEN'.

Note that it carries a security warning:

Security Warning

Modifying the response in case of missing authorization weakens the security of the password, because it reveals to a possible attacker, that his guessed password was right.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.