SP cookie bloat

[Cantor, Scott]

> I definitely wouldn't call it a bug, but tweaking the session cleanup to
> make it remove existing cookies randomly rather than deterministically
> such that multiple parallel requests would potentially remove different
> cookies would probably help.

It can't just randomly clean them up, that would break normal use. It's simply imposing a size limit. It happens to not elegantly expose a controllable limit, but the flooding case doesn't have a viable limit to set so I don't know how it can be accomodated without eventualy blowing up.

> would it be possible to simply not set them unless they are needed?

It wasn't possible to do that easily, they're too separate in the code.

> Ideally by tying their existence into the same configuration directive, or
> if that's not feasible by a separate directive?

It would have to be a separate directive and I didn't see the value at the time. When it's reimplemented it will undoubtedly be one setting since it will probably be a Java property in the end.

To be blunt...the whole point of this was that I was sick of people bitching about CSRF so I finally fixed it since "everybody else does that", apparently. If people won't even turn the feature on, I can't help that, but the assumption was that it would be on by default in the future. So it doesn't help a lot to say "you don't need the cookie if it's off".

I guess I'm left with...what in the heck is it supposed to do? I agree flooding is a problem, but  how can that be allowed at all? If nothing else, you're pounding somebody's IdP with pointless requests. Were it my IdP, I'd be taking issue with that...

I don't know what the SP could do about flooding since it doesn't know the context for the requests.

Generally, when the reason for the flooding is silly stuff like embedded graphics, that's an easy fix: stop sticking the SP in front of the images.

-- Scott