我相信你的问题存在误解。会话和数据库扮演着不同的角色,尽管它们都是数据存储。会话是临时存储,而数据库是永久存储。数据保留在数据库中,直到您明确删除它,但会话带有到期日期。数据库和会话之间还有另一个主要区别,称为会话 ID。Session-id 是一种将 HTTP 请求与服务器上的适当会话数据相关联的方法。会话 ID 通常作为 cookie 在 Web 服务器和浏览器之间来回传输。这是会话如何工作的典型场景:
浏览器的第一个请求已到达 Web 服务器。服务器上的软件处理传入的请求并看到它不包含会话 ID(因为它是第一个请求)。因此,会为此请求创建一个随机生成的唯一会话 ID,并与响应一起发送回客户端(无论它可能是什么)。在服务器上还创建了一个与新创建的会话 ID 相关联的存储。
用户请求同一服务器上的另一个页面。这一次,当请求到达服务器时,它带有一个 session-id,因此与其为该请求创建新的 session-id 不同,而是加载与其关联的数据。如果服务器上的软件更改了数据,则在将响应发送回浏览器时将其存储回存储器。
从现在开始,发送到 Web 服务器的每个请求都会加载相同的会话数据。除非从服务器中删除会话数据或会话 ID,否则此过程将继续。
在所解释的场景中,会话用于保持与请求相关联的数据。会话数据的主要功能之一是存储用户的凭证数据。这是另一种情况:
用户打开网站的第一页。为他创建了一个 session-id 并将其发送回他的浏览器。
用户进入登录页面并填写表格并按下提交按钮。
登录请求已到达服务器。用户名和密码相互检查,如果验证,则在会话数据中提到该会话 ID 属于哪个用户。
从现在开始,服务器上到达的每个请求都会加载包含该请求来自谁的会话数据,并且与数据库无关(除非您将数据库用作会话数据存储)。
这种后期场景称为authentication
,这意味着验证请求是否来自他们声称来自谁。在一般情况下,一旦用户通过身份验证,就无需再次对其进行身份验证(除非会话被破坏)。就身份验证而言,唯一必须使用数据库的部分是当您要检查用户名和密码时。
此外,还有另一种情况称为authorization
. 在这种情况下,您知道谁在问什么,唯一剩下的就是检查他是否被允许这样做。您知道谁在询问,因为您在会话数据中拥有经过验证的凭据,其中加载了传入请求的会话 ID。授权可以分为两种类型。首先,您可以检查是否允许用户执行请求的操作。其次,您可能想进一步检查并查看是否允许用户对请求的数据执行请求的操作。第一种类型是称为ACL
(访问控制列表)的库的用途,第二种通常在每个项目中单独实现。
ACL 是一个函数(简单地说),它接收请求者用户和请求的操作(称为resource
)并返回一个布尔值,指示是否允许用户执行该操作。准确地说,资源可以是复合的(如Files_Delete
或Files_Read
)。ACL 功能需要说明谁可以做什么。大多数开发人员在用户通过身份验证时从永久存储(如数据库)加载这些数据,并将其存储在会话数据中,以防止从数据库重新加载。这是可能的,因为 ACL 数据不是那么大,并且可以将其存储在会话中。因此,通常使用 ACL 进行授权也不需要数据库访问(在创建之后)。
剩下的唯一讨论是当您想要检查请求者是否允许对请求的数据执行请求的操作时。通常这里的数据是指数据库的记录,通常有很多。因此,将如此大量的数据存储在数据库本身以外的任何地方都是不合逻辑的。而且由于它已经在数据库中,没有比 SQL 更适合查询谁可以在哪条记录上做什么的工具了。这是您需要访问数据库以验证用户请求的授权的地方。但在所有其他情况下,会话数据就足够了。
总之,在所有解释的场景中,只有一个需要数据库访问。其他的只能使用会话数据来完成。