API CORS - configured to have somedomain2.com explicitly added to whitelist (with appropriate headers/credentials options set)
Essentially, the ss-opt and X-UAId cookies are blocked by the browser SameSite policy because they do not have the secure attribute applied to them (despite the SameSite=None attribute coming through in the header) which is a requirement for SameSite. Oddly, the ss-id and ss-pid cookies both have the SameSite and Secure attributes set correctly and are therefore accepted and stored by the browser. What this results in is both session cookies (ss-id & ss-pid) being sent back on subsequent api requests but, due to the missing ss-opt cookie (previously blocked by the browser), the “temp” ss-id cookie is used by default rather than the “permanent” ss-pid. The user’s “perm” session is not found resulting in a new “temp” session being created with the ss-id key and the IAuthSession.IsAuthenticated flag being false (by default).
As you can see from the below image of the returned headers, whilst the ss-id & ss-pid seem to have been processed correctly according to the above host config, ss-opt & X-UAId seem to have skipped applying the “UseSecureCookies = true” config setting.
Our AppHost configuration is as follows:
- UseSameSiteCookies = false (should result in “SameSite=None” attribute)
- UseSecureCookies = true (should result in “secure” attribute)
- AllowNonHttpOnlyCookies = false (Not relevant here but can this be renamed and inverted to UseHttpOnlyCookies = true? The current name is horrible.)
If there’s something I’m missing from our host config or my understanding isn’t complete of the behaviour then please let me know, otherwise this may be a bug.
- ServiceStack 5.9.0
- Chrome (v86.0.4240.111)/Edge (v86.0.622.51)
Turning off the following browser settings sees the process complete successfully: