User context switching not working

Hi @heddn.

Thanks. I have a few questions though:
1. You've mentioned (in emails or in support ticket) that it doesn't work only for some exact users. Does it mean that on your Drupal instance, you have some saml/sso modules installed that serve only some users thus context user impersonating doesn't work only in those cases? I would like to reproduce and debug the issue before merging this branch, I'm not sure where exactly the session gets dropped/overridden.
2. From our logs I see you've tried the context debug module on your instances (dev and prod I believe). On prod, a request to `/global/en/admin/content/block/N` gives 403 response code with `1006*****` response body, which seems to be a Cloudflare firewall-related. Sounds like a request for grabbing context didn't even hit the Drupal instance. Just want to clarify if this is related or if you reconfigured something on your side. Otherwise, it's not clear how it works for one Drupal user and not for another.

Btw this "switcher" is based on masquerade module, it might be affected by the issue as well I believe.

1) The user being used is inconsequential. Early testing seemed to indicate it was important, but that isn't the case.
2) Almost all of my testing was on localdev without any CF. I could reproduce it there without any issue. The MR here "fixed" the problem.

Did you try enabling "Context silent user authentication" option? If enabled it skips user login/logout hooks being called when impersonating. It might be the case that some of saml/sso modules hook into those actions and override session.

Yes, that was attempted. We also tested with users who aren't even in SAML. Same result. After debugging things, it is entirely around the fact that impersonation of another user via their session and a session cookie generated for that user doesn't work until we save the session.

> After debugging things, it is entirely around the fact that impersonation of another user via their session and a session cookie generated for that user doesn't work until we save the session.

It doesn't sound right. It works in our test envs and on other clients too. Please share your Drupal core version, I will debug on that exact core.

p.s. just curious, doesn't masquerade → also work on your env? We use exactly the same approach as they use.

After working on 📌 Support layout builder translations Active , we aren't hitting a scenario any more where an anonymous user is trying to access a restricted block edit page. That said, I still don't think this hurts anything and will only solve a few issues for some customers. See related MR.

I ran functional tests with this change. Unfortunately, context related tests failed (testContextSendingByCron and some others).

I'm going to postpone this issue since you are not hitting this scenario anymore. Will get back to it once I have a capacity.