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