一些上下文...如果您不耐烦，请跳到底部提问...
我试图将我( future )网站上的四个页面的访问权限限制为具有有效用户名和密码对的用户。为此，我有一个简单的 PHP/HTML 表单......在我的 PHP/HTML 表单中，客户端输入用户名和密码，点击“提交”......数据进入 POST，另一个 PHP 脚本验证用户/通过在我的 mySQL 数据库中使用 SELECT 来获得密码对...
用户密码表: uid (PRIMARY KEY,INT), 用户名 (varchar 32), 密码 (char 128)
如果匹配成功，则它会查找访问表以查看特定用户名可以访问的页面(1 表示访问，0 表示无访问):
用户访问表: uid (PRIMARY KEY,INT), securename0(TINYINT), securepage1(TINYINT)...
然后 PHP 脚本会打印出指向他们有权访问的安全页面的链接。如果我理解正确的话，我读过的文章和书籍指出，您通常在客户端存储一个 cookie，其 session ID 指向服务器上的一个 session 文件，该文件存储用户名/密码对和任何其他 session 变量，直到它超时或用户注销。
我不想花钱购买专用服务器。因此，所有 PHP session 信息都集中保存在服务器上，连同在其上运行的其他客户的其他六个网站。这让我感到非常不安全......
问题是...规避所有这些并在我自己的 mySQL 表中存储/跟踪每个用户的 session 信息是否更安全？即.像这样:
session 表: sessionkey (PRIMARYKEY, CHAR(128)), uid(INT), expiretimedate(DATETIME), accesstosecurepage0 (TINYINT), accesstosecurepage1(TINYINT)...
因此，当用户点击任何“安全”页面时，它会检查他们的 session ID cookie(如果存在)，然后在 session 表上执行 SELECT 以查看是否存在特定的“sessionkey”，然后根据以下条件授予他们访问权限什么访问安全页面 0、1、2 等。设置为。
这会比替代方案更好吗？还是我在浪费时间？
最佳答案
这个问题与 session 本身一样古老，尽管可能与您的原因略有不同。安全性不是问题，因为 session 劫持发生在有人获取用户的 session ID 并将其发送到服务器时。因此，使用数据库存储 session 数据与使用机器上的文件一样不安全——它们本质上是一回事。
当需要多个服务器来托管一个站点，或者需要跨不同但相关的域存储 session 时，往往会使用数据库 session 。但是，如果不使用预构建的框架，从头开始设置它的工作量要大得多。
如果您不需要此功能，那么使用标准 session 就足够了。
关于php - 使用 mysql 跟踪 session 而不是信任服务器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9541871/