本文简单说了一下我对B/S系统限制登录功能的一点实现，从网上看到好多关于单点登录的讨论，也有好多人把单点登录和限制登录的概念搞混了。
其实，单点登录，最常见的实例便是各大门户网站，在一处登录，就可以到处逛了。而限制登录，是说在一个系统中对权限用户的一种登录限制。比如不允许同一个账号多地点同时登录（可能要和ip等信息绑定）。
我们组去年上线的项目这几天要发布一个新版本，并且要把后台的登录限制做的完善一点。
原来对登录限制的实现方案，就是通过ajax不断的获取当前用户的状态，并将当前时间写入到数据库中，而若是再登录该用户账号，则会比较当前二者的时间差，若在一定的合适范围内，则准许登录系统。否则，提示“已经登录”。这样做其实是有一定局限性的，并且在我们的维护过程中，出现过这个问题，用户的机器突然断电，当再启动，发现一直不能登录后台系统，并提示“已经登录”。经分析得出，这就是因为我们对于登录限制的功能实现与当前系统信息耦合性过强，只是因为计算机系统时间倒退了，便导致我们的系统出现了问题。
即便是，我们进行一定程度上解耦，把两次登陆时间差值的范围改动一下，但只要还是依赖于系统时间的判断，那么这个依赖关系就是无法解除。
我们现在新版本的登录限制实现思路，是通过Session和Cache来交互使用。Session是单用户的会话状态，当用户访问网站时，便会产生一个SessionId，并存在于Cookies中，每次向服务器请求，便会发送这个Cookies，再从服务器端检索是否有这个SessionId保存的数据，我们在项目中每个页面都会判断是否Sission值为null。Cache是在服务器端的缓存，能够被所有用户访问和共享。
是的，我就是用Cache来处理全局，Session来处理局部。
当用户提交登录页面表单后，我们会判断在服务器端的Cache缓存中是否有该用户账号信息存留，若有，则说明该用户正在登陆状态或非正常退出系统(我已经在“退出系统”中设置了清空服务器端的相关Cache信息)。
但是由于考虑到用户的实际应用环境，很多时候店面客流量很大，由于操作不当很容易非正常退出系统，若是让用户为了成功再次登录后台系统，而去白白等上十几分钟，给用户的使用感受是非常不好的。若是设置Cache缓存的Timeout太小的话，有可能导致用户进行一次常操作而多次登录系统。
经过思考，我给新版本添加了一个超级用户，就是用来处理用户着急登录系统而系统提示“用户正在登录中”这样的问题。思路很简单，用户依旧使用自己的Id登录系统，如下图。登录系统之后，直接进行<退出系统>操作，这样把服务器端的Cache缓存信息清除。这样用户就可以再次重新登录了。
虽然说这样做，一定程度上满足了限制登录的要求，但是实际的使用体验中，还是感觉不方便，就如我们这个项目，目前大多数还是单店运行，没有并网运行，若在排除恶意操作，那么我们很多的验证、限制操作设计便无用。但是，我们不能按照自己的思路来做设计，要尽量多的为用户着想，他们会容易犯什么样的错误，我们要全部规避、有所防范，总之就是一切从客户角度出发。 还有，我们在与客户交流沟通的时候要去合理的的引导他们正确、规范的使用我们的软件，而不是简单一说，随意为之。
我之所以这样设计超级用户，并且以这样的比较繁琐的操作步骤来进行Cache信息的清除，也是为了给用户一种引导，让他们从这样重复、冗余的操作中一点点规整自己的操作习惯。
像这样的限制登录功能，从目前项目的运行来看，给我的感觉基本上就是“弃之可惜，食之无味”。
<推荐阅读>
《作为技术人员出现场,感触颇多》
http://blog.csdn.net/lfsfxy9/archive/2011/02/21/6198826.aspx