Klaus Hueck <[email protected]> writes: > Since users in our usage scenario rarely use more than 5 services at a > time the maximum cookie length considering the FQDN + /logout would be > rather in the order of 200 characters. This shouldn't be a problem I > think. The cookie really just contains the URL of the service without > any other information.
The maximum length of the entire HTTP header, including the cookie headers and everything else that gets sent, is 8K in Apache and 4K in some other servers like nginx. I've managed to exceed that limit with a WebLogin server and a WAS running on the same host using delegated credentials and Active Directory as a KDC (so three cookies: the single sign-on cookie, a proxy cookie containing the TGT, and a credential cookie containing a delegated Kerberos credential). Of course, that's an unusual situation that I created as a test case. I agree that in your case with a maximum of five services, it's probably not a problem, but I'm worried that it could be in the more general case, particularly for people using Active Directory as their KDC. That said, that shouldn't prevent you from proceeding with that approach. I'd just kind of like to support web storage as well in the official release. A third possible alternative is that WebAuth 4.4.0 (which is almost finished) will add support on the WebLogin server for using memcached to store some state data. Initially, this will only be used for optional replay caching and optional temporary account lockout after too many failed login attempts, but it could very easily be used for sitewide logout data as well. The one caveat to that is that memcached doesn't (so far as I can tell) have a pool replication protocol, so one is dependendant on a single memcached server that could, of course, go away. But having sitewide logout fail in that situation and tell the user to close their browser would probably be fine. > Since many users in our department use JavaScript blocker JavaScript is > no alternative. Understood. Indeed, a design goal of WebAuth has been to never *require* JavaScript for anything, and I do want to keep that. -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
