-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop same-site cookies from being wiped when printing in Internet Explorer 11 #2045
Conversation
Thanks for contributing this @gunjam – really amazing investigative work getting to the bottom of that! I've been able to verify the issue by tracking network requests in ngrok. When the 'check your answers' page in our review app is first loaded in IE11 (using BrowserStack), the following requests are made: When pressing 'Print' in the browser several additional network requests are made, including a request for the fallback PNG but also an unexpected request to With this branch checked out, the request to
This fixes a tiny bordered square in IE10 and IE11 that I hadn't noticed before.
We do need to rebase this to pick up the latest changes to our CI setup, which I can do for you now. I'll also add an entry to the changelog. Finally, this will need another review from another member of the team and then we can get it merged. |
I've rebased this, added a test for the @gunjam are you happy with the changelog entry and the updated PR title? I've tried to focus it around the issue it fixes, rather than the change that was made. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with this, pending another review from the team.
More than happy, thanks @36degrees . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this @gunjam 🕵️
@@ -39,7 +39,7 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to correct the above comment to say
an empty data URI xlink:href
instead of
empty xlink:href attribute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @hannalaakso I've made the changes you suggested. Thanks!
This prevents SVG supporting versions of IE from making a network request to `/` when the print dialog is opened, which can cause session cookies to be cleared if SameSite is set to 'Strict'.
Hi @gunjam, thanks again for your contribution. We'd like to add your name to a list of contributors in some of our release comms. Can you let me know your full name, where you work and your Slack handle on 'UK Government Digital'? Thanks kindly! |
The current fallback uses an `<image>` element, which is interpreted differently depending on whether it’s parsed in the context of SVG or HTML. We include an `xlink:href` attribute on the `<image>` tag to prevent versions of IE which support SVG from downloading the fallback image when they don't need to. However, this approach has proved problematic – IE11 still requests the fallback PNG when printing, which can cause issues with sessions (#2045) and an attempted fix for that issue by using a blank data uri has now caused further issues with Content Security Policies (#2203). Switch to the simpler approach of using conditional comments for the header fallback PNG, targeting Internet Explorer 8 specifically. We can then use a good old-fashioned `<img>` tag. This does mean that browsers that do not support SVG other than Internet Explorer 8 will not be able to see the crown emblem. According to Can I Use, the other main browser that does not support SVG that we may need to consider is Android 2.1 - 2.3 [1]. Between 2020-05-14 and 2021-04-30 analytics for GOV.UK shows 6,792 (0.00041%) sessions from 4,343 (0.00119%) users using Android 2.x, out of 577,929,096 sessions from 77,144,107 users. By comparison, in the same period we saw 36,075 sessions (0.00217%) from 28,963 users (0.00791%) using IE8. It appears that Android 2.x browsers just omit the SVG entirely – there’s no ‘broken image’ displayed – these users just see ‘GOV.UK’ without the crown. Given the very low volume of traffic from these browsers, this seems like an acceptable thing to do. We could have removed the fallback PNG entirely, however our browser support explicitly states support for Internet Explorer 8 (‘although components may not look perfect’) and we know that some service teams do have a disproprtionate number of IE8 users – which is unlikely to be the case for Android 2. [1]:https://caniuse.com/svg
The current fallback uses an `<image>` element, which is interpreted differently depending on whether it’s parsed in the context of SVG or HTML. We include an `xlink:href` attribute on the `<image>` tag to prevent versions of IE which support SVG from downloading the fallback image when they don't need to. However, this approach has proved problematic – IE11 still requests the fallback PNG when printing, which can cause issues with sessions (#2045) and an attempted fix for that issue by using a blank data uri has now caused further issues with Content Security Policies (#2203). Switch to the simpler approach of using conditional comments for the header fallback PNG, targeting Internet Explorer 8 specifically. We can then use a good old-fashioned `<img>` tag. This does mean that browsers that do not support SVG other than Internet Explorer 8 will not be able to see the crown emblem. According to Can I Use, the other main browser that does not support SVG that we may need to consider is Android 2.1 - 2.3 [1]. Between 2020-05-14 and 2021-04-30 analytics for GOV.UK shows 6,792 (0.00041%) sessions from 4,343 (0.00119%) users using Android 2.x, out of 577,929,096 sessions from 77,144,107 users. By comparison, in the same period we saw 36,075 sessions (0.00217%) from 28,963 users (0.00791%) using IE8. It appears that Android 2.x browsers just omit the SVG entirely – there’s no ‘broken image’ displayed – these users just see ‘GOV.UK’ without the crown. Given the very low volume of traffic from these browsers, this seems like an acceptable thing to do. We could have removed the fallback PNG entirely, however our browser support explicitly states support for Internet Explorer 8 (‘although components may not look perfect’) and we know that some service teams do have a disproprtionate number of IE8 users – which is unlikely to be the case for Android 2. [1]:https://caniuse.com/svg
The current fallback uses an `<image>` element, which is interpreted differently depending on whether it’s parsed in the context of SVG or HTML. We include an `xlink:href` attribute on the `<image>` tag to prevent versions of IE which support SVG from downloading the fallback image when they don't need to. However, this approach has proved problematic – IE11 still requests the fallback PNG when printing, which can cause issues with sessions (#2045) and an attempted fix for that issue by using a blank data uri has now caused further issues with Content Security Policies (#2203). Switch to the simpler approach of using conditional comments for the header fallback PNG, targeting Internet Explorer 8 specifically. We can then use a good old-fashioned `<img>` tag. This does mean that browsers that do not support SVG other than Internet Explorer 8 will not be able to see the crown emblem. According to Can I Use, the other main browser that does not support SVG that we may need to consider is Android 2.1 - 2.3 [1]. Between 2020-05-14 and 2021-04-30 analytics for GOV.UK shows 6,792 (0.00041%) sessions from 4,343 (0.00119%) users using Android 2.x, out of 577,929,096 sessions from 77,144,107 users. By comparison, in the same period we saw 36,075 sessions (0.00217%) from 28,963 users (0.00791%) using IE8. It appears that Android 2.x browsers just omit the SVG entirely – there’s no ‘broken image’ displayed – these users just see ‘GOV.UK’ without the crown. Given the very low volume of traffic from these browsers, this seems like an acceptable thing to do. We could have removed the fallback PNG entirely, however our browser support explicitly states support for Internet Explorer 8 (‘although components may not look perfect’) and we know that some service teams do have a disproprtionate number of IE8 users – which is unlikely to be the case for Android 2. [1]:https://caniuse.com/svg
tl;dr this fixes an issue where a service with
SameSite: Strict
set on its session cookies will have them wiped in IE when opening the print dialog if they serve a page on the root of their domain.We were experiencing an odd issue in our service where some users were unexpectantly getting sent back to the beginning of the service from the Check Your Answers page. After some research with users this appeared to only happen after they attempted to print their answers. A lot of head scratching later I figured out what was going on: when a user in IE11 (and presumably lower) opens the print dialog, the browser re-requests all uncached assets and in doing will make a GET request for
xlink:href
value in the crown SVG image tag, even though it's blank. It'll resolve this to the root of the domain which for us is the first page of our service. The problem is that if you haveSameSite: Strict
set on your cookies, IE won't send them when making the image request to/
so our service will act as if this is a new session and send a new session cookie with the response, which IE will then propagate back into the page resetting the session cookie. On submission, the user is now trying to access a page at the end of the service with a blank session, so gets sent back to the start.A pretty odd issue, typical of IE, but will affect any service with a session based page being served on
/
, unless you setSameSite
to something other thanStrict
, which we don't really want to do.The simplest solution to this I've come up with, is to set the empty
xlink:href
value to a blank data URI so that the browser will not initiate a network request. I've also set the SVGdisplay
attribute tonone
so browsers do no render a small blank SVG in place.