Safari observed caching the IdP login page

[Cantor, Scott]

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" <users-bounces at shibboleth.net on behalf of larscheidt at wisc.edu> 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