Roundup Tracker - Issues

Message7533

Author rouilj
Recipients marcus.priesch, rouilj, schlatterbeck
Date 2022-05-17.15:01:15
Message-id <20220517150112.C1D7A6A0289@pe15.cs.umb.edu>
In-reply-to <71471f9c-d38e-35a2-0739-835fc127475f@priesch.co.at>
Hi Marcus:

No worries about time off. It's a good idea in general.  I'll update
the docs.

In message <71471f9c-d38e-35a2-0739-835fc127475f@priesch.co.at>,
Marcus Priesch writes:
>> An open question is what to return if an origin check fails in
>> preflight or in cors.
>> * return some 400 value
>> * remove Access-Control-Allow-Origin header with no other change.
>>   This will fail a prefetch and prevent the data returned from being
>>   accessible to JavaScript IIUC.
>
>i would vote for 403 (maybe 404 to not reveal too much)

404 indicates the URL endpoint is bad. The URL is fine it's just the
request that is bad. Some proxy's/caches invalidate data on a 404 (GET
method). I am not sure if a 404 with an OPTIONS method could be cached
or cause side effects.

Per

https://stackoverflow.com/questions/33739107/how-to-handle-an-invalid-cors-preflight-request

tomcat returns a 403. But the MDN docs say this about 403:

  ...Unlike 401 Unauthorized, the client's identity is known to the server. 

We aren't sending credentials/identity for a preflight, so I don't
think 403 is right. 403 is correct if a CORS /rest request occurred
for a user without "Rest Access" permissions. 401 might be valid even
though CORS isn't an authentication/authorization mechanism.

https://stackoverflow.com/questions/14015118/what-is-the-expected-response-to-an-invalid-cors-request

notes the result code is not specified and recommends 403.

https://stackoverflow.com/questions/69427953/cors-cross-origin-resource-sharing-origin-validation-failure

indicates returning 200 without the Access-Control-Allow-Origin header.

>and btw: how is the status now with the support for preflight requests ? 
>what can i do ? - the patch you provided in an earlier post was rejected 
>by you ... is there anything i can test or help ?

When I rejected my previous patch, I added a new patch. Try:

  https://issues.roundup-tracker.org/file1784/Fixed1_Allow_CORS_Preflight_through_rest_handlers.patch

and see if that works for you.

This patch does not add "Origin" to the Vary header. For your
testing purposes it doesn't matter. In real life, the
Access-Control-Allow-Origin could be different depending on the
origin.

Also can you confirm that your are using your patch with
csrf_enforce_header_origin turned off (not yes or required). The
preflight request skips the CSRF check, but with origin checks turned
on it should reject the actual CORS request.

Looks like I will need to allow the user to provide a list of valid
origins and add the tracker origin to the list by default. If * is in
the origin list, I pass any origin. I should do this for xmlrpc and
rest. For the html interface, only the tracker will be valid.

Also can you post the headers from one of your CORS requests? I need
to verify that the checks for Host/X-Forwarded-Host and Referer will
pass. (I have a feeling Referer won't.)

Have a great week.
History
Date User Action Args
2022-05-17 15:01:15rouiljsetrecipients: + rouilj, schlatterbeck, marcus.priesch
2022-05-17 15:01:15rouiljlinkissue2551203 messages
2022-05-17 15:01:15rouiljcreate