|
Malcolm Turnbull wrote:
We aren't an ecommerce site, but we do require some sort of
login/authentication to use our site.
I've been involved with a mid sized ecommerce company for about 4 years
and we've had very few problems using cookies for state (storred in a
single backend db.) Its fast and easy...
Same here, until the past 4 months or so. It seems that the latest and
greatest anti-virus software and pop-up blockers disable cookies (among
other things that they have no business doing). Rumor has it that new
versions of IE will disable cookies by default. A good portion of IE6
users won't accept cookies unless your site publishes a P3P of some sort.
We get appx. 4000 people/day (9000 logins/day), and we were getting up
to 10 cookie related problems a day to the helpdesk. I'd estimate that
there were at probably 2-10x that who had problems, but never reported
it. In 3 years of requiring cookies, we had only one nasty email about
our requirement to have cookies enabled.
At any rate, we now use a different system to autheticate a user. 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.
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.
--
-Jacob
|
