|
Joseph Mack wrote:
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.
sid + (cookie, IP, browser ident) is only used to authenticate the user.
The session data itself stores all sorts of things, such as temporary
user prefs, some of the things the user looked at, a bit of caching to
cut down on subsequent db queries, things like that. Only part of that
session data persists between logins, but it has to be stored somewhere
between pages.
Our situation is a little different from your average e-commerce store.
We can't just identify a shopping cart + items by a unique sid. We
need the session data to act as a ram drive of sorts for data that needs
to be quickly accessed, multiple times per page.
All of that temp data is stored in an array, and serialize()'d. PHP's
serialize is pretty compact, but it still expands out. For example, a
simple int value of the login timestamp looks like:
s:8:"login_ts";i:1084802982;
The 1/2mb is the MAXIMUM we allow to store. Typical is more in the
3-10kb range. Average size over 49627 rows of session data is 3134b
right now.
What's going to happen to your session data when IE6 disallows cookies?
It'll still work. The sid cookie is only one of several hints we can
use to authenticate the user.
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?
There is an upper limit on the GET string IE will send. Somewhere
around 1 or 2 kb. When it hits the limit, if you use javascript to
submit the form, it'll error out. If you just use a <input
type="submit">, it'll just not work. For sites that will never hit that
limit, passing in the session data would work.
However, there should still be checks to authenticate the user, mostly
to prevent problems when they share links with friends.
One solution to the user modifying the string is to pass in a public key:
Kpu = public key
Kpr = private key
md5 = standard MD5 sum algo
session = your serialized session data
Kpu = md5(md5(session + Kpr) + md5(Kpr)) (or some variation, see the
HTTP RFC for an example with the HTTP DIGEST authentication)
Then you can authenticate that the session data hasn't been modified by
checking your computed Kpu against the Kpu that was passed in from the
GET/POST. If they match, the session data probably hasn't been
modified. If they don't, there is a very good chance the data was
either corrupted in transit or corrupted by the user.
It's only as strong as the Kpr used and whatever the collision
probability of the md5 algorithm.
--
-Jacob
Listingbook.com
|
