为什么 OpenCart 管理面板上的授权逻辑会设计成这样（很奇怪）？
Why would authorization logic on OpenCart Admin Panel design like this (weired)?
我们有很多认证授权方式（OAuth、2FA等）来保证我们电商平台账号的安全。
我最近仔细研究了 OpenCart 3.0.2.0 的管理员登录逻辑，并试图弄清楚为什么授权逻辑设计成这样：
- 将会话 table 中的 user_token 存储在数据库中（酷）
- 在PHP内存中存储记录的状态（酷）
- 在管理员用户的浏览器中存储 user_token（酷）
- 给出令牌过期的持续时间（酷）
- 继续在URL GET变量上到处携带user_token(???)
我们可以检查来自管理员用户的 user_token 是否有效并且在我们的数据库中的会话 table 中（登录时检查），然后我们可以跟踪记录的状态在 PHP 内存中，我们还可以检查此会话是否已过期。
问题是：为什么我们仍然需要在 url get 变量上保持 user_token 无处不在？
user_token 变量是后来在互联网上讨论此安全漏洞后添加的。
令牌的想法是防止黑客向用户发送 link，其中包含 url 中的恶意代码，该代码会使用经过管理员身份验证的会话来破解 opencart 管理面板。
有了令牌，OpenCart 会检查它并注销管理员以防令牌不正确。
我们有很多认证授权方式（OAuth、2FA等）来保证我们电商平台账号的安全。
我最近仔细研究了 OpenCart 3.0.2.0 的管理员登录逻辑，并试图弄清楚为什么授权逻辑设计成这样：
- 将会话 table 中的 user_token 存储在数据库中（酷）
- 在PHP内存中存储记录的状态（酷）
- 在管理员用户的浏览器中存储 user_token（酷）
- 给出令牌过期的持续时间（酷）
- 继续在URL GET变量上到处携带user_token(???)
我们可以检查来自管理员用户的 user_token 是否有效并且在我们的数据库中的会话 table 中（登录时检查），然后我们可以跟踪记录的状态在 PHP 内存中，我们还可以检查此会话是否已过期。
问题是：为什么我们仍然需要在 url get 变量上保持 user_token 无处不在？
user_token 变量是后来在互联网上讨论此安全漏洞后添加的。
令牌的想法是防止黑客向用户发送 link，其中包含 url 中的恶意代码，该代码会使用经过管理员身份验证的会话来破解 opencart 管理面板。
有了令牌，OpenCart 会检查它并注销管理员以防令牌不正确。