2

I want users to be authenticated when calling a specific HTTP method, while not needing to be authenticated when calling other HTTP methods. I use the Limit directive, because that's supposed to do what I want, but I can't get it to work.

SSLVerifyClient none
<Location /foo>
    SSLVerifyClient none
    <Limit PUT>
        SSLVerifyClient require
    </Limit>
</Location>

It seems that the last SSLVerifyClient statement is always executed, no matter which call I make (PUT, DELETE)

I also tried to use LimitExcept but it has the same faulty behavior.

Since I cannot find answers online, I assume that this is a no-brainer, but I started working on this last week to fill in for a colleague that is on holiday. Can someone help me?

Improve this question

1 Answer 1

Reset to default
0

It seems that Limit directive only works for restricting access. Other directives inside it might not work at all or not work as you expect. In your case it might not be able to trigger different values of SSLVerifyClient depending on the type of request.

A workaround might be to create different directories or aliases, configured with different values of SSLVerifyClient directive and possibly handling different set of HTTP methods.

http://httpd.apache.org/docs/current/mod/core.html#limit:

<Limit> Directive

Description: Restrict enclosed access controls to only certain HTTP methods.

The purpose of the directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the bracket will have no effect.

Improve this answer
3
  • And with restricting access you mean allow or deny, ignoring whether or not the right SSL certificate is present? I guess in my case, any url is allowed and the certificate is normally only checked later. The SSLVerifyClient not working as expected inside the Limit directive means in this case that it is executed always.
    – neXus
    Feb 17, 2015 at 14:02
  • It would be a bummer to have to change the urls just to circumvent this problem. But it would work.
    – neXus
    Feb 17, 2015 at 14:04
  • 1
    Using different SSL configuration for the same URL but different HTTP methods just sounds like asking for trouble. Think of reused connections, sessions, browser caching, there is just too much that can go wrong and not work as expected. Using a different URL for each configuration would be a much safer solution.
    – dezlov
    Feb 17, 2015 at 14:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .