On Fri, 21 Apr 2000, Gunther Birznieks wrote:
> At 01:44 PM 4/20/00 -0500, Matt Carothers wrote:
>
> >Another big win is that the secure token can persist across multiple
> >servers.
>
> What would prevent the token from being across multiple servers otherwise?
It's beneficial when compared to a non-token system like apache's basic
auth, where your browser won't (or shouldn't anyway) send your credentials
to multiple hosts, and you end up having to enter your password over and
over.
Regarding cookies vs. url mangling, you could use urls as easily as
cookies. Just unpack your encrypted data into hex and shove it right
into the url. It would make for some pretty long urls, but I've seen
worse on search engines. :)
> The nice thing about your encryption is that it makes the cookie into a
> kind of pseudo client certificate -- providing information. But at the same
> time, I would be concerned that that sort of Encryption overhead (on top of
> SSL) seems like it would add load to the server.
>
> How does it work for you in real world use?
It works great for my purposes, but my servers are very lightly loaded.
> I suppose it poses an
> interesting tradeoff... with that method you don't have to maintain real
> session persistence since you have it in your decrypted data? So then you
> can avoid an extra IO going to a database or flatfile to retrieve the
> session info.
>
> Am I getting this correct?
Exactly. It's a cpu vs. i/o tradeoff. It takes more processor power to
decrypt/encrypt a cookie on each hit, but you only have to query the database
once for each session.
- Matt
