CEF Forum

I'm working on an upgrade from CEF 88 to 104 and ran into a difference in behavior that I'm having trouble tracking down.

In my program we make a request that is not associated with a browser to download some asset. The url is http and it gets redirected to https. The server side is expecting a cookie, which does exist, but for whatever reason doesn't end up in the redirected request. We specify UR_FLAG_ALLOW_STORED_CREDENTIALS on the request. When I use the old CEF 88 build it all just works.

If I add UR_FLAG_STOP_ON_REDIRECT and manually generate another request for the redirect then the cookie is there, but since this was not necessary before I'm hesitant to make this change without fully understanding why this would be necessary now.

Just curious if anyone has any ideas on whether this is expected due to changes in Chromium or if I'm just missing something obvious.

What kind of redirect? It could be related to https://developers.google.com/search/bl ... one-secure

See also https://bitbucket.org/chromiumembedded/ ... s-set-with

I actually stumbled upon that second url when I was originally looking for a solution. Strangely, setting first party fixes the issue on mac but not on windows. It isn't clear to me what the difference would be but I'm not too familiar with where platform-specific logic enters into requests. I forgot to mention this in my first post.

The status code is 307. I'll dig more into your first link and see if I can narrow down what could be going on.

Thanks,
Joe.

Messing around a bit more, I think I at least understand why the cookie isn't being sent. When I do the normal request I'm seeing

Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty

When I do the manually generated requests for each redirect I end up with

Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty

So if I'm understanding this correctly, it's flagging my normal request as cross-site and therefore not sending my cookies. All the requests are to the same host, the only difference is the scheme. Since this is being sent outside the context of a browser, does it even make sense for this to think I'm generating a cross-site request?

HTTP to HTTPS is now considered cross-site. See https://web.dev/schemeful-samesite/

Interesting, ok I guess this is expected behavior then. I'll see if we can just fix this on the server side. Thanks for your help

Although I'm wondering if there is just a way to flag this request as user-generated - since this isn't associated with a browser, I'm still not entirely sure marking this request as cross-site makes sense. Pasting the http url in chrome works, presumably because it treats this as a user request