Hello!

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

> # HG changeset patch
> # User Sampson Crowley <sampsonsprojects@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/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel