google 到的各种有关 Cookie,Session 的文章,以及各种 demo, 差别都好大。。。
那么,有没有大家都认可的,常用的,类似“行业标准”的做法呢?
那么,有没有大家都认可的,常用的,类似“行业标准”的做法呢?
|
1
SAML,Radius这种?
|
|
2
|
|
3
@thenewbie 脱离场景谈最佳实践,难啊。
我的习惯: 数据库设置一张 Users 表,与认证有关系的字段为 { Id, 用户名,加密密码,密码盐,验证标识 } 默认验证标识为 null。用户登录时,输入明文密码,传输至 Server,加上密码盐,计算密码是否正确。正确的话生成一个验证标识(Guid)存入数据库,并将验证标识写入用户端Cookie,用户端Cookie的加密是一定要做的,各个框架都有自己的办法,不赘述。 当用户访问网站时,会检测用户送到服务端的Cookie,是否有正确的验证标识,如果有,则用户被当成已经认证的;没有或者不正确,则重定向用户到登录页。 这样也会有一个问题:用户在机器A上登录不退出,又在机器B上登录了,这时候因为验证标识变化了,机器A上的用户如果刷新页面,则会因为本机Cookie验证标识和服务器端不一致,要求重新登陆。这个这不符合场景要求,也可以通过维护多个验证标识的方式解决,也不赘述。 抛砖引玉,验证还比较好做,授权就忒复杂了。 |
|
4
@AntiGameZ 仅仅是“用户登录时,输入明文密码,传输至 Server,加上密码盐,计算密码是否正确。”怎么会 “A上登录不退出,又在机器B上登录了,验证标识变了” ?在生成标识的时候,还加进判断 ip 了么?
PS: 授权啥的... 通常都把信息放到session中么? |
|
5
@thenewbie 因为 A 和 B 得到的验证标识不是用一个, 所以不一样.
|
|
thedevil5032Feb 28, 2013
6
@thenewbie 打错, 同一个.
|
|
7
@thedevil5032 @AntiGameZ 呃... 好吧,刚刚误解了... orz... 我刚刚怎么想的 >.<
|
|
8
@thenewbie cookie,session一般都是框架去维护的,真需要从头自己设计的情况不多。Discuz快是因为将很多数据都直接丢在磁盘上做了缓存。既然是小应用,确保程序逻辑清晰简单,不要有明显的漏洞(比如明文密码,或者某些页面/函数忘记添加验证条件)就差不多了。性能方面,毕竟对于同一个用户来说,登录操作不是频发的,只需要把用户在验证时候需要的一些必须数据在内存中做个缓存即可。即便不做,我认为也是可以接受的。
|