|
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. 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?
Thanks
Joe
--
Joseph Mack PhD, High Performance Computing & Scientific Visualization
SAIC, Supporting the EPA Research Triangle Park, NC 919-541-0007
Federal Contact - John B. Smith 919-541-1087 - smith.johnb@xxxxxxx
|
