LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: how do you maintain state on LVS'ed databases/shopping carts?

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: how do you maintain state on LVS'ed databases/shopping carts?
From: Horms <horms@xxxxxxxxxxxx>
Date: Fri, 21 May 2004 12:08:37 +0900
On Mon, May 17, 2004 at 02:22:25PM -0400, Joseph Mack wrote:
> Jacob Coby wrote:
> > 
> > We pass in a sid per page, and use cookies, IP address, browser ident, and
> > other metrics to authenticate the user.  Sensitive areas of the site
> > (such as those requiring a credit card) also use SSL.
> > 
> > All session data is stored in a single database, as a serialized PHP
> > array.  There can be up to 1/2 MB of session data, and part of the
> > session data persists between logins, so it doesn't make sense for us to
> > put session data in the cookie or to store it on the webservers.
> 
> Can you tell us more about how you do this. It's hard to see 0.5M of session 
> data
> out of sid per page, cookies, IP, browser ident.
> 
> What's going to happen to your session data when IE6 disallows cookies?
> 
> > > Putting the sessionid in the URL i.e. GET is ugly and slightly less 
> > > secure.
> > > I guess you could POST it on every page but would that be slower than
> > > cookies ? (I think so)
> > 
> > POST is marginally slower than GET if you look at the HTTP spec.  There
> > is an additonal request header per variable.  GET is only *very
> > slightly* less secure.  POST, and cookies are of equal security levels,
> > and they're all trivial to send using command line tools.
> 
> until recently I'd thought that putting the session data into the URL
> (rather than a cookie) was the way to go, till someone pointed out that
> the user could manipulated the URL. 

Is there anything to stop a cookie or post from being manipulated
by an end user. Sure, it might be margionally more difficult
as you would probably need some (command like) tool, rather than
just changing the URL directly in your given browser. But it
should still be trivial.

> In that case, could the session id
> be put in a long enough string in the URL such that any attempt to alter
> it would result in an invalid string?

I rearely write web pages. But if I was to do something like this
I would make the string in the URL a hash (md5, sha1 or something like
that), which should make guessing a valid string rather difficult.
I would do the same in a cookie or a post. I would imagine something
like this is pretty common practice.

-- 
Horms
<Prev in Thread] Current Thread [Next in Thread>