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

[Sampson Crowley]

Maxim the work around you provided is invalid,

    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;
    }

returns 'invalid condition "!$allow" by nginx and the service fails to start

On Thu, Jan 16, 2020 at 12:24 PM Sampson Crowley <
sampson at downundersports.com> wrote:

> the fact is that CORS is part of the whatwg spec, endpoint consumers don't
> differentiate what section of the spec it's a part of, and requiring
> credentials on a preflight request is against the spec, so no, it's not
> compliant. https://bugzilla.mozilla.org/show_bug.cgi?id=1019603#c9
>
> On Thu, Jan 16, 2020 at 11:09 AM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Thu, Jan 16, 2020 at 08:18:10AM -0700, Sampson Crowley 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
>>
>> You assume that CORS is a part of HTTP specification.  It's not.
>> Neither it's a part of SSL / TLS specification, which is a
>> separate one.  Further, all current variants of ssl_verify_client
>> are HTTP-complaint, as well as SSL/TLS-complaint.  Further, I
>> suspect that these are also CORS-complaint (though I never checked
>> the exact wording of the CORS specification), even if some of them
>> may prevent CORS preflight requests from working.
>>
>> > 2)  I don't see how "compliant" is misleading to be "compliant" with how
>> > things are SUPPOSED to work in the first place
>>
>> Sure.  And things already complaint.  The question is how exactly
>> things work, and what exactly happens in a given situation.
>> Introducing a separate "complaint" variant suggests that other
>> variants aren't complaint, which is not true.  Further, it doesn't
>> define to what exactly things are expected to be complaint.
>>
>> --
>> 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/be07c527/attachment.htm>