|
锁定老帖子 主题：关于rails大容量网站部署的性能讨论
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-05-15
AreYouOK? 写道 robbin 写道 多说一句cookie和session的群集解决方案。我现在是这样做的：
用户登陆的时候给他一个cookie，存放userId，使用32位uuid(Hibernate生成)，不使用int，是为了避免被hack。此外同时给这个用户分配一个Session，存放user对象。 然后我再写一个webwork Interceptor，拦截所有的动态访问请求，如果他有cookie，但是没有session，就根据cookie里面的userId查数据库，给他session里面放入user。 这样就很完美了，例如用户在clone1上面登陆，然后用户请求被分发到clone2，这个时候clone2上面有cookie无session，但是我的拦截器会用cookie查数据库给他session。这样每个节点只需要访问一次数据库设置session而已。而应用程序里面照常使用session，从session里面拿user对象，不需要改一行代码。只要该节点有session，就直接使用session，如果该节点无session，就从cookie里面去userId访问数据库设置一次session。兼顾了性能和群集部署的无状态，哈哈，完美吧。 好像安全有问题 如果我没有理解错的话，放在cookie里面的那个userId和数据库里面存的userId是相同的吧，那我只要记下这个cookie的名字和userId，以后每次都能伪造出这个cookie绕过登录了。 url里面可能有其他用户的userId（比如查看用户资料的url，应该是类似这样的吧viewUser?userId=xxx），那么我得到其他用户的userId，也能伪造出其他用户的cookie登录了 即使cookie是加密过的userId，至少在一个已经登录的浏览器里面得到cookie的值，就能伪造出这个cookie以这个浏览器的当前登录用户进入 主要问题就在于，同一个用户记录登录信息的cookie，不管什么时候登录，它始终是同一个值。而tomcat管理的jsessionId是随机生成的，即使得到这个cookie的值，在session超时以后就不再有效 所以当你不在自己的私人机器上面使用的时候，登陆系统请不要选择“记住cookie” |
| 返回顶楼 | |
|
发表时间：2006-05-15
robbin 写道 AreYouOK? 写道 robbin 写道 多说一句cookie和session的群集解决方案。我现在是这样做的：
用户登陆的时候给他一个cookie，存放userId，使用32位uuid(Hibernate生成)，不使用int，是为了避免被hack。此外同时给这个用户分配一个Session，存放user对象。 然后我再写一个webwork Interceptor，拦截所有的动态访问请求，如果他有cookie，但是没有session，就根据cookie里面的userId查数据库，给他session里面放入user。 这样就很完美了，例如用户在clone1上面登陆，然后用户请求被分发到clone2，这个时候clone2上面有cookie无session，但是我的拦截器会用cookie查数据库给他session。这样每个节点只需要访问一次数据库设置session而已。而应用程序里面照常使用session，从session里面拿user对象，不需要改一行代码。只要该节点有session，就直接使用session，如果该节点无session，就从cookie里面去userId访问数据库设置一次session。兼顾了性能和群集部署的无状态，哈哈，完美吧。 好像安全有问题 如果我没有理解错的话，放在cookie里面的那个userId和数据库里面存的userId是相同的吧，那我只要记下这个cookie的名字和userId，以后每次都能伪造出这个cookie绕过登录了。 url里面可能有其他用户的userId（比如查看用户资料的url，应该是类似这样的吧viewUser?userId=xxx），那么我得到其他用户的userId，也能伪造出其他用户的cookie登录了 即使cookie是加密过的userId，至少在一个已经登录的浏览器里面得到cookie的值，就能伪造出这个cookie以这个浏览器的当前登录用户进入 主要问题就在于，同一个用户记录登录信息的cookie，不管什么时候登录，它始终是同一个值。而tomcat管理的jsessionId是随机生成的，即使得到这个cookie的值，在session超时以后就不再有效 所以当你不在自己的私人机器上面使用的时候，登陆系统请不要选择“记住cookie” 嗯，如果这是解决方案的话，那我太伤心了 假如系统是一个web mail，那我可以趁朋友不再电脑前面的时候偷到这个永久有效的cookie（或者通过其它的手段如sniffer等），以后就可以一直偷看信件了。这个朋友知道信件被偷看后，居然束手无策，连修改密码也没有用，只能把这个id费掉了。假如这个系统就是JE论坛，又会如何？ 要是不用这种单点登录的认证方式，只能自己实现随机的通行令牌了，象CAS那样，需要做一个专门的认证server来维护session。 |
| 返回顶楼 | |
|
发表时间：2006-05-15
clark 写道 zgd 写道 理论上用户会不停clone1 clone2的跳，那就是clone1和clone2不停创建session了
这个问题可以用LVS解决。 事情复杂化了吧 |
| 返回顶楼 | |
|
发表时间：2006-05-15
不知道robbin理解我说会不停创建session的问题没有
用户第一次访问clone1 创建了一个session session id纪录在cookie了 第二次访问变成了clone2（用户是不知道变了） 在clone2创建了一个session session id纪录在cookie，覆盖了原来的session id 第三次访问变成clone1 虽然clone1是已经创建了session 但是这个session id不见了，于是又创建一个新的session 不知道是怎么解决这个问题的 |
| 返回顶楼 | |
|
发表时间：2006-05-15
引用 第三次访问变成clone1
虽然clone1是已经创建了session 但是这个session id不见了，于是又创建一个新的session 这个session id不会不见的。除非你已经关闭浏览器了，既然关闭浏览器，那么当然session就没有了。 |
| 返回顶楼 | |
|
发表时间：2006-05-15
robbin 写道 引用 第三次访问变成clone1
虽然clone1是已经创建了session 但是这个session id不见了，于是又创建一个新的session 这个session id不会不见的。除非你已经关闭浏览器了，既然关闭浏览器，那么当然session就没有了。 对 session 理解有误, 看这篇 http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp?Id=10 在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。 |
| 返回顶楼 | |
|
发表时间：2006-05-15
robbin 写道 引用 第三次访问变成clone1
虽然clone1是已经创建了session 但是这个session id不见了，于是又创建一个新的session 这个session id不会不见的。除非你已经关闭浏览器了，既然关闭浏览器，那么当然session就没有了。 session id是不会不见的，但是拿clone2的session id去clone 1里面是取不到session的，会通过你设置的保存userid的cookie再去创建一个session |
| 返回顶楼 | |
|
发表时间：2006-05-15
AreYouOK? 写道 robbin 写道 AreYouOK? 写道 robbin 写道 多说一句cookie和session的群集解决方案。我现在是这样做的：
用户登陆的时候给他一个cookie，存放userId，使用32位uuid(Hibernate生成)，不使用int，是为了避免被hack。此外同时给这个用户分配一个Session，存放user对象。 然后我再写一个webwork Interceptor，拦截所有的动态访问请求，如果他有cookie，但是没有session，就根据cookie里面的userId查数据库，给他session里面放入user。 这样就很完美了，例如用户在clone1上面登陆，然后用户请求被分发到clone2，这个时候clone2上面有cookie无session，但是我的拦截器会用cookie查数据库给他session。这样每个节点只需要访问一次数据库设置session而已。而应用程序里面照常使用session，从session里面拿user对象，不需要改一行代码。只要该节点有session，就直接使用session，如果该节点无session，就从cookie里面去userId访问数据库设置一次session。兼顾了性能和群集部署的无状态，哈哈，完美吧。 好像安全有问题 如果我没有理解错的话，放在cookie里面的那个userId和数据库里面存的userId是相同的吧，那我只要记下这个cookie的名字和userId，以后每次都能伪造出这个cookie绕过登录了。 url里面可能有其他用户的userId（比如查看用户资料的url，应该是类似这样的吧viewUser?userId=xxx），那么我得到其他用户的userId，也能伪造出其他用户的cookie登录了 即使cookie是加密过的userId，至少在一个已经登录的浏览器里面得到cookie的值，就能伪造出这个cookie以这个浏览器的当前登录用户进入 主要问题就在于，同一个用户记录登录信息的cookie，不管什么时候登录，它始终是同一个值。而tomcat管理的jsessionId是随机生成的，即使得到这个cookie的值，在session超时以后就不再有效 所以当你不在自己的私人机器上面使用的时候，登陆系统请不要选择“记住cookie” 嗯，如果这是解决方案的话，那我太伤心了 假如系统是一个web mail，那我可以趁朋友不再电脑前面的时候偷到这个永久有效的cookie（或者通过其它的手段如sniffer等），以后就可以一直偷看信件了。这个朋友知道信件被偷看后，居然束手无策，连修改密码也没有用，只能把这个id费掉了。假如这个系统就是JE论坛，又会如何？ 要是不用这种单点登录的认证方式，只能自己实现随机的通行令牌了，象CAS那样，需要做一个专门的认证server来维护session。 google就可以通过copy cookie来绕过等录，可以拿ie和firefox试验一下 |
| 返回顶楼 | |
|
发表时间：2006-05-15
Feiing 写道 robbin 写道 引用 第三次访问变成clone1
虽然clone1是已经创建了session 但是这个session id不见了，于是又创建一个新的session 这个session id不会不见的。除非你已经关闭浏览器了，既然关闭浏览器，那么当然session就没有了。 对 session 理解有误, 看这篇 http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp?Id=10 在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。 被你抓住了一个语病，谢谢。不过关于这一点我是了解的很清楚滴，去年做一个大项目的调优，还用JProbe钻研过WebSphere的Session实现机制和Tomcat的Session实现机制。HttpSession在服务器端的实现实际上就是一个Map，key是生成的一串UUID字符串，value是你放入session的值。 关闭浏览器以后再打开，浏览器不可能再送同样的session ID了，因此，session的机制也是不保险的。 假设你上网的时候我记住你的session ID，然后我用这个sessionID访问网站，一样可以冒充你。和setAge(-1)的cookie是没有任何区别的。 |
| 返回顶楼 | |
|
发表时间：2006-05-15
zgd 写道 clark 写道 zgd 写道 理论上用户会不停clone1 clone2的跳，那就是clone1和clone2不停创建session了
这个问题可以用LVS解决。 事情复杂化了吧 但是，用LVS性能和功能要优于用 lighttpd, apache, tomcat, weblogic 等做负载均衡分发。 |
| 返回顶楼 | |
