[PATCH] Add "compliant" option to ssl_verify_client for CORS support

[Maxim Dounin]

Hello!

On Wed, Jan 15, 2020 at 01:51:34PM -0700, sampsonsprojects at gmail.com wrote:

> # HG changeset patch
> # User Sampson Crowley <sampsonsprojects at gmail.com>
> # Date 1579118065 25200
> #      Wed Jan 15 12:54:25 2020 -0700
> # Node ID 4ba211814386f2e4adcd855b27d7d2534a5036a7
> # Parent  8a7b59347401bba7b018c7292409ab095ce83466
> Add "compliant" option to ssl_verify_client for CORS support
> 
> The CORS Spec specifically prohibits any form of credentials
> during preflight checks. Because "on" fails ALL requests if
> a certificate is not provided, it becomes impossible to use
> "ssl_verify_client on;" with spec compliant browsers and CORS,
> namely Firefox. I didnt want to break any configs that rely on
> or prefer that failure to occur, so I added an additional option
> to allow only OPTIONS requests to bypass the client certificate
> validation.

Thanks for the patch.

In no particular order:

- The argument name suggested looks wrong and misleading, it says 
  nothing about what the particular setting is expected to do.

- The behaviour you are implementing can be configured without any 
  additional arguments, by using "ssl_verify_client optional;" and 
  appropriate checks during request processing.  For example:

    ssl_verify_client optional;

    set $allow 0;

    if ($ssl_client_verify = OK) {
        set $allow 1;
    }

    if ($method = OPTIONS) {
        set $allow 1;
    }

    if (!$allow) {
        return 496;
    }

While the currently required configuration might be a bit too 
complex for typical tasks, using CORS with SSL certificate 
verification is probably rare enough to don't care.  On the other 
hand, if we nevertheless want to simplify it, a better solution 
might be to do this with a simplier checks during request 
processing, instead of introduction of a CORS-specific argument to 
an SSL-level configuration directive.

-- 
Maxim Dounin
http://mdounin.ru/