无论我如何推理，似乎都没有安全的方法来实现客户端呈现的单页应用程序，该应用程序使用/访问 session 信息进行身份验证(通过 cookie)，而不会严重损害安全性。我主要是想构建一个 React 应用程序，但似乎我需要使用 SSR 来构建它以获得相对安全的身份验证版本。
我特别想到的用例是用户登录或注册，然后获取带有 session ID 的 cookie。从那里，在服务器端实现中，我可以简单地根据服务器存储的 session 是否具有关联的用户 ID 设置条件渲染，然后从那里提取用户信息并显示它。
但是，我无法想到客户端呈现的解决方案，其中用户可以在不易欺骗的 cookie 上单独使用 session id。一些不安全的实现包括使用浏览器存储(本地/ session )。谢谢。
最佳答案
我认为这里的主要问题是您混合了网页的两个部分(至少根据 HTML 规定的实现)并将它们都视为敏感信息。
网页中有两个主要部分 - 第一个是显示格式，第二个是数据。客户端渲染/单页应用程序的假设是格式本身不敏感，只有数据需要保护。
如果是这种情况，您应该将客户端重定向到登录行为视为生活质量功能。服务器上的数据端点仍然会受到保护 - 这意味着理论上，未经身份验证的用户可能会破坏他正在提供的静态 HTML 并提取页面布局和模板 - 但如果没有数据来填充它们，这些将毫无意义 - 这是 protected 部分。
实际上 - 您的最终产品将是一个单页面应用程序，它向各种 API 端点发出请求以获取数据并填写所请求的页面模板。您甚至不需要存储复杂的 session 状态 - 一个简单的标志通知客户端是否已通过身份验证就足够了(这超出了您通常用于服务器端身份验证的范围，例如 cookie 或 token )
现在假设我是一个不怀好意的恶意用户 - 我可以“欺骗” - 或者只是打开浏览器开发工具并将 isAuthenticated 标志设置为 true 让我跳过登录屏幕 - 现在我该怎么办？理论上，我可以导航到 my-service/super-secret，而无需在本地重定向回客户端的登录页面 - 然后，一旦相关页面尝试使用不存在的凭据从服务器加载数据，它就会失败 - 最好的情况显示错误消息，最坏的情况显示一些内部异常，并且 View 显示损坏的模板。
简单强调一下:
A.如果您想要保护的是您的模板，那么就无法实现此客户端。
B.如果您想要保护的是您的数据，那么您应该将控制/阻止用户导航到 protected 页面视为一种生活质量功能，而不是安全功能，因为在为该特定页面提供数据时，这将在服务器上实现。
关于node.js - 是否可以使用客户端呈现的应用程序和 session 进行身份验证？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50594616/