CORS issues in SEB 3.1.0 about seb-win-refactoring HOT 17 CLOSED

An update was made to cefsharp/CefSharp#3277 (comment) with a confirmation that the issue is caused by updated CORS policies in recent Chrome versions, and the suggestion to remove custom headers to external domains.

from seb-win-refactoring.

@jeroenhabets We will release 3.1.1 before December the 24th, for sure.

from seb-win-refactoring.

On Twitter.com, the browser does indeed try to perform a preflight before loading assets via GET and the response is 400, either because GET requests should normally not trigger preflights, or because these special headers are unrecognized:

I'm not sure if it's a good solution, but skipping the BEK and config-key for any cross-domain requests would solve the issue I think, but I don't know if any exam systems rely on those being included cross-domain. It might however even make sense to not leak these to third parties.

from seb-win-refactoring.

Thanks for the detailed report! To be honest, I never had to dig that deep with CefSharp / CEF until now and my web development knowledge is a bit old, I need to first catch up on a few things here (e.g. preflights)...

I can reproduce the issue but I am not sure whether there is much I can do: I am using IResourceRequestHandler.OnBeforeResourceLoad to append the custom headers, and looking at the API, I couldn't right away find an indicator via which I could identify those preflight / cross-domain requests (if I understood your solution proposal correctly it would be the idea to omit the BEK / CK headers on those requests). Or am I misunderstanding or missing something?

from seb-win-refactoring.

Thanks for acknowledging the issue. I'm afraid I don't have any knowledge of the inner workings of SEB or of CefSharp, and my suggestion was just a quick thought, however if you have access to the current website domain (via the IWebBrowser object) and the domain of the request (via the IRequest object), you could perhaps try to skip the custom headers if they don't match?

from seb-win-refactoring.

And to be clear, preflight requests are made automatically due to the extra headers. Omitting the custom headers will automatically get rid of the preflights.

You can read more at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS, but in short – a preflight (the HTTP verb OPTIONS) is a small request performed before another to ask for "permission" to perform the actual request. It is very common for POST requests cross-domain, but GET-requests with non-standard headers will also trigger preflights.

from seb-win-refactoring.

But it seems to work on Mac and iOS, although those versions also add the same headers to all HTTP requests...

Theoretically we wouldn't have to add those headers to requests to other domains, as long as the exam web application isn't affected. All requests from the exam applications should contain the custom header, as otherwise (depending on how they check for BEK/CK) they might trigger an access error.

from seb-win-refactoring.

There are definitely browser discrepancies at play here, and Google has made quite a lot of changes to cross-domain policies this year (for instance the default value for the SameSite cookie setting). Since this problem is not present in SEB 3.0.1, it seems like the update of Chrome has affected this. Other browsers may follow in future updates.

Here's some references to CORS-changes in Chrome 85, although I'm not sure this is the exact change that is causing these issues: https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

from seb-win-refactoring.

Excellent, thanks for the further information and explications. I'll study the issue closer and will see whether I can find a solution.

from seb-win-refactoring.

This may be the same issue, and if that is the case it is probably caused by upstream changes in CEF. It is perhaps not a bug but rather a policy change, and if so, the solution is for apps to avoid custom headers, and for servers to allow preflights (as it looks like that might be more common in the future, even for GET-requests).

cefsharp/CefSharp#3277

from seb-win-refactoring.

Okay, thanks for the update. So this means that I will need to filter the requests and only add our custom headers to requests which target the same domain as the currently loaded page. Do you know whether I need to filter by domain or even by subdomain (e.g. test.org or even subdomain.test.org)?

from seb-win-refactoring.

Yes precisely, and CORS do apply to subdomains as well (and even to the protocol and port, but that might not be an issue here).

So yes, comparing the complete domain of the loaded page with the complete domain of the request and only including the custom headers should they match.

from seb-win-refactoring.

Ah, I see. Excellent, thanks for the help. I will introduce the filter with version 3.1.1, which we plan to release end of this year.

from seb-win-refactoring.

Okay, I think I fixed the issue. @Krisell Could you please test the build linked below and verify that it now works as it should?

https://sebdev-let.ethz.ch/project/AppVeyor/seb-win-refactoring/builds/261

from seb-win-refactoring.

@dbuechel I have tested now and all of the previous issues have been resolved. I also checked in the developer tools and verified that the BEK and CK are sent for on-domain requests but not for cross-domain. Great work!

from seb-win-refactoring.

Excellent, thanks for the quick response and your help in general. In that case the issue will be resolved with the upcoming version 3.1.1.

from seb-win-refactoring.

@dbuechel our customers have been impacted by this so I wonder if you can share the planned 3.1.1 release date?

from seb-win-refactoring.