Users may want to embed a login to ThinLinc inside one of their other web pages using an iframe. Unfortunately, that is starting to break, at least if the containing page and Web Access are on different sites (in HTTP same-site terminology). What happens is that the WebSocket connection failed, and the user is greeted with: > Failed to connect to server This is because the browsers are changing their default cookie behaviour in accordance with this suggestion: https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html In short, cookies are no longer included in every request to the site that issued them. Instead, they are only included when the page loading the resource is the same site as the resource. Unfortunately for us, this also covers iframe usage, as the browser considers the container page to be the page loading things, not the Web Access page inside the iframe. And without our auth cookie, the WebSocket connection fails. Chrome has already implemented this, and will print the following under "Issues": > Indicate whether a cookie is intended to be set in a cross-site context by > specifying its SameSite attribute Firefox is going to implement it, and currently warns: > Cookie “auth_cookie” does not have a proper “SameSite” attribute value. Soon, > cookies without the “SameSite” attribute or with an invalid value will be > treated as “Lax”. This means that the cookie will no longer be sent in third > party contexts. If your application depends on this cookie being available in > such contexts, please add the “SameSite=None“ attribute to it. To know more > about the “SameSite“ attribute, read > https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite If we explicitly set "SameSite" to the new "Lax" default policy, then Firefox also breaks: > Cookie “auth_cookie” has been rejected because it is in a cross-site context > and its “SameSite” is “Lax” or “Strict”.
There is also an issue if the containing site uses http instead of https: > ThinLinc Web Access encountered an error: > > The operation is insecure. > https://lab-95.lkpg.cendio.se:300/app/webutil.js > > readSetting@https://lab-95.lkpg.cendio.se:300/app/webutil.js:159:9 > start@https://lab-95.lkpg.cendio.se:300/app/ui.js:94:21 > prime/<@https://lab-95.lkpg.cendio.se:300/app/ui.js:49:27 > promise callback*prime@https://lab-95.lkpg.cendio.se:300/app/ui.js:47:39 > @https://lab-95.lkpg.cendio.se:300/app/ui.js:1758:4
The most obvious way to fix this is to set "SameSite" to "none", which effectively gets us back to our previous behaviour. The question is if we want this new protection the browsers give us. And related, do we want to have even more blocking of iframes to prevent attacks such as clickjacking? There (expectedly) are no obvious security issues going back to the old model. The containing page JavaScript cannot access the iframe's cookies, and the cookie is limited to only be included for the correct WebSocket URL.
Note that even with that fix, some browsers might still block third-party cookies, depending on privacy settings. We may want to have an explicit check for things to give a better user error message.
NICE DCV has this documentation on embedding their web client in an iframe: https://docs.aws.amazon.com/dcv/latest/adminguide/embed-in-iframe.html
