让我们想象一个客户端在索引页面上打开你的nuxt.js网站。从那里,他们进行身份验证(您为此使用了@nuxtjs/auth-next(。然后,他们移动到一个只有经过身份验证的用户才能看到的安全页面。这个安全页面是你的";页面";具有middleware: ["auth"]
的文件夹。
现在,这个页面如何真正安全
我的意思是,恶意用户难道不能在没有经过身份验证的情况下对页面进行处理并访问它吗?因为";安全性";在这种情况下只在客户端实现,对吗[编辑]
你的应用程序最终是一个SPA,如果你想绕过中间件进行安全检查,你可以禁用页面上的JS。但是,由于没有直接生成内容,您将看不到任何内容,因为它不在这里(作为静态文件(。
如果你的应用程序是同构的(基本上有一个ssr: true
(,auth模块仍然会禁用对这些页面的访问(你可以仔细检查(。
最后,关键信息在以下情况下接收:
- 您确实有一个有效的JWT令牌(登录后(
- 您向后端提交HTTP查询
- 后端确认它并且令牌是有效的
- 后端通过HTTP响应向您提供敏感信息
最后,您的客户端代码不需要是安全的。如果有人以某种方式侵入您的客户端状态并到达敏感页面,他仍然没有有效的JWT令牌,因为验证仍然在后端进行
只有在将正确的凭据发送到后端并让后端验证这些凭据时才能生成的凭据。
现在,这个页面如何真正安全?
如果客户端提供了有效的访问令牌,则会通过请求提供受保护的内容。受保护的内容是在运行时提供的。
因为;安全性";在这种情况下只在客户端实现,对吗?
安全性不仅在客户端实现。前提是:访问令牌是通过身份验证服务器的身份验证流安全获得的。如果这听起来不清楚,我建议阅读更多关于auth流的内容。Auth0有一些关于不同流的好文档。https://auth0.com/docs/authorization/flows
那么,只向经过身份验证的用户显示复杂页面的最佳方式是什么?
内容是在运行时提供的。服务器端或客户端。这里有一些Nuxt的设置指南。这是我从列表中找到的第一个(Auth0(。https://auth.nuxtjs.org/providers/auth0
我不知道这些指南是如何更新的,但身份验证服务提供商往往自己也有更新的指南。