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

Benjamin Coddington bcodding at
Wed Dec 12 13:57:15 PST 2012

On Dec 12, 2012, at 12:45 PM, Russ Allbery wrote:

> 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.

We have WAS tracking in a cookie for logout and are aware that max header
sizes could be a problem for us -- we're growing services pretty quickly --
but it hasn't come up as a problem yet (that we know of).

One of the most attractive things about WebAuth is its stateless server..
this is a beautiful thing.

> 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.

There are ways to make memcached redundant and reliable.  Though, if I had
to choose between maintaining a fault-tolerant stateful platform or
abandoning those with script disabled, I'd leave the scriptless behind.  Is
that terrible?  Maybe, but WebAuth is a rock right now.

One last thing -- Klaus, you might think about not sending the user's
browser on a wild ride around a ring of WASes -- rather have the WebLogin
server generate a page with a resource to load from each WAS.  That way,
users won't get lost on the ride if a WAS behaves badly, and you don't have
to worry about sending the WAS chain info along the way.


More information about the webauth-info mailing list