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

[Sampson Crowley]

What if it's changed to "preflight_optional" or "on_spec_compliant" is that
a better description in your opinion?

On Thu, Jan 16, 2020, 08:18 Sampson Crowley <sampson at downundersports.com>
wrote:

> 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/8996773e/attachment.htm>