Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

Logout mechanism

Russ Allbery eagle at
Wed Dec 12 09:45:42 PST 2012

Klaus Hueck <klaus.hueck at> 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 <eagle at>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University

More information about the webauth-info mailing list