不同的网站需要不同的会话表吗？
我有多个 Web 应用程序 (PHP)，这些应用程序从自己的域向不同的客户提供服务。每个域显然都有单独的 cookie 和会话（域和路径均设置正确）。
我是否需要在数据库中为每个网站设置一个完全独立的会话表以尝试确保唯一的会话？我猜我不需要这样做，因为如果我们使用文件支持的会话，那么每个服务器都使用相同的会话存储。所以我猜想通过数据库存储我也可以重新使用该表。
只是对于会话代码（我使用的是 ADODB），我看不到任何在会话创建期间处理会话 ID 冲突的代码。
I have multiple web applications (PHP) which are being served to different customers from their own domain. Each domain obviously has separate cookies and sessions (with the domains and paths all set correctly).
Should I need to set up a completely separate sessions table in the database for each website to try to ensure unique sessions? I'm guessing that I don't need to, because if we were using file-backed sessions, then each server uses the same session-store. So I'm guessing that with a DB-store I can just re-use the table too.
It is just that with the session code (I am using ADODB), I can not see any code to handle a session ID collision during session create.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它不会给您的应用程序带来任何问题，但是，为了安全起见，我会使用不同的表，除非合并所有会话是您网站上某些功能的一部分。
我以前没有做过，但我真的不认为会有任何问题。
It won't cause your application any problems, however, just for the sake of security I would use different tables unless consolidating all sessions is part of some feature on your site.
I haven't done it before, but I really do not think there would be any problems.
您可以修改会话 ID 以包含短站点前缀。只需修改您的创建会话以在创建会话之前调用 session_id($new_id) 即可。
这还允许您列出每个搜索前缀的站点的所有当前会话。更优化的解决方案是将会话密钥拆分为两个字段，分别按前缀和唯一键、前缀索引进行索引。您将需要修改会话创建函数才能实现此目的。
您甚至可以通过此前缀进行验证并拒绝会话（如果绑定到其他网站）以提高安全性。
否则，如果您的会话 ID 正确生成，您就不应该遇到冲突问题。
You can modify a session id to include a short site prefix. Just modify your create session to call session_id($new_id) before creating a session.
This will also allow you to list all current sessions per site searching for the prefix. More optimal solution would be to split a session key in two fields, indexed both by prefix and by the unique key,prefix index. You will need to modify your session create function in order to implement this.
You can even validate by this prefix and reject session if tied to the other web site improving the security.
Otherwise if your session id is properly generated you should not have problems with collisions.