Search Mailing List Archives
eagle at windlord.stanford.edu
Wed Dec 12 15:29:31 PST 2012
Benjamin Coddington <bcodding at uvm.edu> writes:
> 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).
That's a good data point. We should get one of your solutions into the
tree, then, if it's working for folks. :)
> One of the most attractive things about WebAuth is its stateless
> server.. this is a beautiful thing.
Thank you! We put a lot of work into designing it that way and made a few
compromises to make it work, but we agree that it's really nice to have
the server structured that way. I think one of the things that WebAuth
has benefitted from is that all of us who have worked on it have also run
services in production.
> 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.
The nice thing about logout is that if it doesn't work, you're no worse
off than you are right now, and the user just needs to close the browser.
That makes me willing to use more compromises, since there's a useful
> 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.
Yeah, this is a good point. Also, one of the WAS's may be down.
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
More information about the webauth-info