表少了一列：你原先的表是:TABLE1（USER PASSWD）增加的表示： TABLE2 (ID USER COOKIE TIME）用户主动注销则删除TABLE2的COOKIE即可。 用户直接关闭浏览器，则由crontab定时扫TABLE2，清理now()-TIME超过指定时间的行。某USER登陆，检查TABLE2该USER的行数， 小于10则生成COOKIE并插入TABLE2，COOKIE返回用户。 大于10则提示不能登陆。对于USER登陆情况，有一种情况是可以攻击服务器的，即不断的登陆但不提交COOKIE，可以迅速的占用10个该USER的登陆名额，这个问题可以为TABLE2增加IP字段进行安全过滤。即便不做这个安全策略，在crontab定时删除时也会在超时后清理掉COOKIE。
userid | sessionid
ip user_id last_time假设10分钟内算为在线
WHERE last_time+600 > time() 加 GROUP BY user_id 大于10个的话就不允许登录咯。
last_time+600 < time()的删掉。具体还得实践测试……
用户每次都注销的话，那么操作数据库-1就好了。 用户不注销的话，那么数据库应该在session过期的同时计数-1，这样才对用户比较合理。但是很难让session的有效期和计数-1自动的关联运行, 也就是某个登陆session过期了，而数据库里还没有-1，这对用户就不公平了。所以，如果能够注册一个session过期的回调来操作数据库计数-1就好了，可惜不知道有没有php.ini可以配置调用个回调php文件？ 估计没有。。所以，我最终给出的方案为：用户不注销就永远保持其登陆状态，依靠一个单独的COOKIE维护由crontab跑一个php定时脚本，对那些登陆状态保持超过N长的人删除其数据库的COOKIE记录并给技术-1，这样就让位其他用户了，而且原先登陆的那位同学也没话可说，只能重新试图登陆了。增加一张表：AUTO_ID USER COOKIE， 每个USER的每个登陆点对应一个COOKIE，限制该表同一个USER的COOKIE不超过10即限制了10人登陆，只要把COOKIE生成发给每个登陆者，只要它们不注销，它们在一段时间内都保持在线，PHP检测他们是谁与否就是用查数据库里的COOKIE。为了清理那些没注销的用户，只能跑crontab定时清理了。
总结！~~~~~ 其实就是因为SESSION总会过期，过期了就无从追踪了，所以需要把会话持久化到数据库！！！
再其次，因为SESSION过期没法回调函数，所以只有持久化之后定期跑crontab清理超时COOKIE~~~~
表少了一列：你原先的表是:TABLE1（USER PASSWD）增加的表示：
TABLE2 (ID USER COOKIE TIME）用户主动注销则删除TABLE2的COOKIE即可。
用户直接关闭浏览器，则由crontab定时扫TABLE2，清理now()-TIME超过指定时间的行。某USER登陆，检查TABLE2该USER的行数，
小于10则生成COOKIE并插入TABLE2，COOKIE返回用户。
大于10则提示不能登陆。对于USER登陆情况，有一种情况是可以攻击服务器的，即不断的登陆但不提交COOKIE，可以迅速的占用10个该USER的登陆名额，这个问题可以为TABLE2增加IP字段进行安全过滤。即便不做这个安全策略，在crontab定时删除时也会在超时后清理掉COOKIE。
http://ca3.php.net/manual/en/class.sessionhandler.php
当然某些楼上的方法也都可以做到看你自己的具体需求和现有实现而定
看过这个session handler，不知道过期会不会回调destroy callback，只好去试验一下了。这不是伪装COOKIE的问题，如果一个攻击者连用户的账号密码都知道了，他登陆10次你又耐他何。
我不知道版主何以提出这样的疑问？
大家可以拿一些开源的论坛或CMS测试一下，是否真的一个系统只允许同一个帐号被登录一次呢？
我想开源系统都做不到的，我不知道这里有几个人能完整回答出来！