Hello! On Wed, Jan 15, 2020 at 01:51:34PM -0700, [email protected] wrote:
> # HG changeset patch > # User Sampson Crowley <[email protected]> > # 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
