如果一个人只知道把所学精髓共享，他永远不会有更大的提升，我这也算是有利于人类的进步吧
传统的用户登陆模式则是User提供验证信息给服务器，然后服务器进行验证，如果成功则给用户一个凭证，这个凭证有效性可谓是无限大，如果服务端密码不修改这个验证可能永远登陆，还可能一个凭证N个user享用。这样照成的安全性极差。
现在我们DBS中有两张表，一张user表（uid，pwd，key），还有一张log表（title，text，uid），log表uid外键user表uid。传统的模式，可能是用uid inner join查询log表。
我将这种模式进行修改，用户登陆时候提供uid和pwd给DBS进行验证。验证成功后将自动生成的key存放入这条记录的key列中。然后将key凭证发给user保存。我们也可以用实施语句进行管理 update user set key = '' where uid ='' and pwd = ''，这样我们就将key和用户名密码进行绑定。
之后我们队用户数据进行访问时候 不用uid作为查询条件，而用key查询 外键 log表。在user每次登陆 修改密码等时候将他的key重新修改。这样就会让另外的user无法通过key外键到log表，来保证数据的安全性，前提是key的复杂度够高，无法出现雷同。最佳的方式（uid和pwd取几位hash+随机生成代码+提取服务器时间hash）
退出登录的时候我们将key设为null。这样代表离线，有人可能会问如果用户没有按照正常的方式即直接关闭浏览器，很简单，微软提供了给我们Global.asax，他是用来后台管理 ，里面有一个Session_End方法则是当前客户端断开时促发事件，sesson对应的是当前会话，这时候我们可以通过user 端sesson里面保存的key数值对数据库进行修改。
在关闭浏览器时候服务器并不会马上执行，而是session。timeout时间结束在次触发 ， 这时候我们可以再Session_Start 里面修改session.TIMEOUT 的数值。最小1分钟
传统的用户登陆模式则是User提供验证信息给服务器，然后服务器进行验证，如果成功则给用户一个凭证，这个凭证有效性可谓是无限大，如果服务端密码不修改这个验证可能永远登陆，还可能一个凭证N个user享用。这样照成的安全性极差。
现在我们DBS中有两张表，一张user表（uid，pwd，key），还有一张log表（title，text，uid），log表uid外键user表uid。传统的模式，可能是用uid inner join查询log表。
我将这种模式进行修改，用户登陆时候提供uid和pwd给DBS进行验证。验证成功后将自动生成的key存放入这条记录的key列中。然后将key凭证发给user保存。我们也可以用实施语句进行管理 update user set key = '' where uid ='' and pwd = ''，这样我们就将key和用户名密码进行绑定。
之后我们队用户数据进行访问时候 不用uid作为查询条件，而用key查询 外键 log表。在user每次登陆 修改密码等时候将他的key重新修改。这样就会让另外的user无法通过key外键到log表，来保证数据的安全性，前提是key的复杂度够高，无法出现雷同。最佳的方式（uid和pwd取几位hash+随机生成代码+提取服务器时间hash）
退出登录的时候我们将key设为null。这样代表离线，有人可能会问如果用户没有按照正常的方式即直接关闭浏览器，很简单，微软提供了给我们Global.asax，他是用来后台管理 ，里面有一个Session_End方法则是当前客户端断开时促发事件，sesson对应的是当前会话，这时候我们可以通过user 端sesson里面保存的key数值对数据库进行修改。
在关闭浏览器时候服务器并不会马上执行，而是session。timeout时间结束在次触发 ， 这时候我们可以再Session_Start 里面修改session.TIMEOUT 的数值。最小1分钟
如果用Session ，只要一分钟没有动作就被踢出来。