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

[Sampson Crowley]

1) The consumer shouldn't need a whole series of checks just to actually do
things correctly and be *compliant* with the http specs

2)  I don't see how "compliant" is misleading to be "compliant" with how
things are SUPPOSED to work in the first place

On Thu, Jan 16, 2020, 05:09 Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200116/e47cbcd4/attachment-0001.htm>