Safari observed caching the IdP login page

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Safari observed caching the IdP login page

Ryan Larscheidt-2
I recently moved where the static CSS and image content on our IdP's login page is hosted, but kept it in the old location "just in case".  Luckily it seems, because to my surprise I observed Safari clients continuing to load the CSS and images from the old locations, which implied that they had cached the HTML of the IdP's login page.

After some Googling I found more reports that Safari's caching behavior is a nightmare, but (in theory) adding "Vary: *" to the response headers will fix it.  I have yet to try this, but Apple's login page sets the header so there might be something to that.

I've only seen the IdP set "Cache-Control: no-store" on the profile endpoints, which doesn't appear to be enough.  With the anti-CSRF functionality IdPv4, I can imagine that these Safari clients would be hopelessly broken if they continued caching the login page with stale tokens.

I'm wondering if the IdP could "more aggressively" set cache busting headers (e.g. "Cache-Control: private, no-cache, no-store", "Expires: 0", "Vary: *")?  Does that seem like a reasonable solution?

Thanks,
Ryan
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Safari observed caching the IdP login page

Cantor, Scott E.
OSU's email is fubar, but in case this shows up...some edits from the original note based on my further thinking...

On 1/22/20, 7:03 PM, "users on behalf of Ryan Larscheidt" <[hidden email] on behalf of [hidden email]> wrote:

> I've only seen the IdP set "Cache-Control: no-store" on the profile endpoints, which doesn't appear to be enough.
> With the anti-CSRF functionality IdPv4, I can imagine that these Safari clients would be hopelessly broken if they
> continued caching the login page with stale tokens.

I would sooner turn off a feature than waste time trying to accommodate broken clients, but does the caching of CSS necessarily imply it's caching the login form? Are there fresh requests for the CSS itself at the old location with a referrer implicating the old login form?

If it were, those users would be seeing breakage because the submit action would be wrong already. The flow keys are a primitive and limited kind of CSRF token that would have a similar effect at least occasionally. Even if the s number was pretty much always the same, the e number wouldn't be.

So those should be causing some frequency of stale request error pages, which may be understood, but just pointing it out.

> I'm wondering if the IdP could "more aggressively" set cache busting headers (e.g. "Cache-Control: private, no-cache,
> no-store", "Expires: 0", "Vary: *")?  Does that seem like a reasonable solution?

People can certainly set anything they like, that's why the response filter is open-ended.

We don't actually have anything very aggressive in the IdP. The only place I know of that we set those headers is In some of the SAML message encoders and I saw one or two other small isolated cases.

My IdP seems to be setting Cache-Control: no-store more widely, including login, but I have no actual idea where/why it's doing that.

The key point is that Safari users should be encountering lots of these stale errors in ordinary use if it's really that broken. And I have had no such indication here.
 
-- Scott



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]