indeed, it is use case dependent. The use case here is a common one, free content, paid content, you don't want users giving their creds to all their friends and using it simultaneously.
(It is at best a first order solution, obviously if it becomes obvious that a fair percentage are using the system 24/7, something better is needed (say, bw capping). Not to hard to do, if needed.) As for the other points : 1. hadn't considered people closing the browser, without logging out - thanks. I guess a short session time is needed - say 10 minutes. The idea of pinging using javascript is quite neat, but I dislike the idea of making the server handle say 2 unproductive req's per minute per logged in user. I'd even rather something as ugly a js popup saying "If you close without logging out ..." when the user closes while logged in to that, I think. 2. the issue of someone leaving work with their browser left logged in is pretty insoluble (after all the browser could well be left open, so you still rely on session timeout). If they do it, they have to wait the 10 minutes, or go back to that computer and log out. K-I-S-S ... If you do all that, so that logout will always happen, couldn't you then solve it like this? (There may be a big fat hole in this ... this is hardly my specialist area ...): 1. On successful login (ie good U/P), get last session key for that user which you left in the db last time. 2. Look in the store for that key, see if it has timed out 3. If so, actually log in and write the new key to the db. 4. Otherwise, fail and leave the db alone. 5. On a real actual logout, nullify the key in the db and take it out the session store. That has only one db write per login (and I store last_login time anyhow, so no real increase), and the session store stays out of the db. Regarding volume, well, it's hardly an issue today, but you never know ... thanks for the excellent quality of feedback Daniel -- There's an infinite supply of time, we just don't have it all yet. _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
