[Catalyst] Preventing simultaneous logins
bobtfish at bobtfish.net
Wed Jul 23 22:13:23 BST 2008
On 23 Jul 2008, at 21:20, Wade.Stuart at fallon.com wrote:
> This is actually a pretty "hard" problem -- there is no right
> What if the user clears her browser state while using the site?
> Leaves the
> computer and browser on at work then tries to log in at home on a
I agree that it's a hard problem if you do it the original way round
that was suggested.
However all apps which do that (Facebook as an example) - logging
into a new session kills your old one, and this is pretty easy to do
(given that you force users to have a cookie and etc).
> I think you can gain most of the lockdown of 1 session per user
> if you just track user activity over a X minute period. for
> instance every
> time a user hits your app add a record that is attached to the user
> in the db (src ip, session number, other relevant info). Then do
> inline or if it is too costly, via cron) a check on those entries
> looks for multiple IP/Sessions or whatever you define as multiple
> (given that http is stateless there really is no _safe_
> definition). If
> that process detects usage over your threshold, disable (temp or
> permanent) the account. The same process can clean up entries that
> outside of the time window that you want to look at.
If you in any way expect your site to scale to high volume, I'd
highly recommend avoiding any approach like this.
Your 'hit logging' table is going to be really really slow (and have
massive contention) if you're doing high volume. Also - these lookups
for multiple IPs you're talking about, they're not going to be
indexed, right? (Adding a *single* index on a table will reduce your
max insert speed by 40-60%).
Even if you're cleaning out rows pretty regularly, you're going to
seriously grind the IO on the DB system, and the general IO subsystem
on your database server (not to mention any replication / binlogs /
hot backups & etc that you need), is going to be doing significantly
more work than it needs to, meaning that the general amount of
headroom you have in the system will be that much reduced...
Your session storage could be criticized for the same reasons, but is
actually significantly less work for the DB (updating, not inserting
and deleting - 1/2 the IO and no index overhead as you're re-writing
without changing keys), and can _trivially_ be pushed into memcache
at a later date when you need to. The approach recommended above
requires a relational model, and so moving it to memcache wouldn't
All of that said, unless you're looking to scale to multiple Mb/s of
traffic, then I'm probably being too paranoid - as jay said already,
'right' here is use-case specific :)
More information about the Catalyst