- 主题:前后端分离的项目如何阻止未经认证的前端访问
你这就是装傻白甜了，市场上一半的系统都没有严格的权限控制，你没有这个权限就是把页面藏起来不给你看
【 在 hgoldfish 的大作中提到: 】
:
: 有这种后端？难道不都是在后端判断一下当前登录的用户角色，返回 401 ?
:
: 【 在 iwannabe 的大作中提到: 】
: : 大部分框架分功能权限和数据权限，功能权限是在数据库屏蔽前端的菜单来实现的。
#发自zSMTH-v-@motorola XT2153-1
--
FROM 117.136.111.*
既要大街上裸奔，
又不给人随便看，
有点太那啥了吧……
【 在 iwannabe 的大作中提到: 】
: 没有用，后端暴露的api都可以访问，目前想到的是除了限制refer，还没有想到其他方案当然，如果权限完善的话，也不是什么 ...
--
FROM 114.254.0.*
后端做jwt token校验啊
【 在 iwannabe 的大作中提到: 】
: 比如我在本地起一个前端，连接生产的后端，这样就可以实现一些原来系统不提供的功能
:
: 尤其是开源的代码，怎么防止这种情况发生呢
: --
: 用革命的魔法对抗反革命的魔法
:
:
发自「今日水木 on SHARK KSR-A0」
--
FROM 115.195.193.*
？？这么实现权限控制？？你是来搞笑的么
【 在 iwannabe 的大作中提到: 】
: 大部分框架分功能权限和数据权限，功能权限是在数据库屏蔽前端的菜单来实现的。
: 而我自己如果跑一个前端，就可以绕过功能权限，
:
--
FROM 60.212.7.*
如果后端是java，加个权限filter就行了
不过你不想增加权限模块，又想用权限的功能，就比较难了
【 在 iwannabe 的大作中提到: 】
: 没有用，后端暴露的api都可以访问，目前想到的是除了限制refer，还没有想到其他方案
: 当然，如果权限完善的话，也不是什么大问题
:
--
FROM 114.253.102.*
你真的用过“大部分”框架吗？
【 在 iwannabe 的大作中提到: 】
: 大部分框架分功能权限和数据权限，功能权限是在数据库屏蔽前端的菜单来实现的。
: 而我自己如果跑一个前端，就可以绕过功能权限，
:
--
FROM 101.88.159.*
简单说一下吧，这个技术至少30年前就已经很成熟了，也一点都不复杂。脑子正常的框架都会采用，你非要选那些脑子不正常的那也确实没办法。
1. 使用https通讯，防止当中有人偷窥，这个没有什么好说的。
2. 登录过程，用户通过用户名/密码等等验证方式登录，登录成功，后端发一个随机数（学名session_id）给前端，前端要保存这个数到cookies里。后端会把这个随机数和你登录的账户存到数据库/文件/redis里。由于前端只有这么个随机数，所以无法猜出和后端用户的对应关系。
3. 之后用户的每项请求，都需要附加上这个随机数。后端由于保存了这个数和用户的对应关系，因此可以知道这个请求是哪个用户发出的，由此与存在后端数据库里的权限管理部分交换，拒绝一切越权的操作。如果用户的请求不带这个数，那就说明是未登录的用户。
4. 这个session_id是有寿命的，根据不同网站的安全要求，超时之后简单把这个对应关系删除，这时就相当于用户退出登录了。这时用户再发请求的时候后端数据库找不到对应关系就简单把用户当成未登录用户就可以了。
5. cookie的原理确保了别人无法偷到这个session_id，只有在这台电脑前，这个浏览器本身能知道这个id。这个id足够长也可以保证很难通过碰撞的方式伪造出别人的ID。
6. 以上过程很成熟了，所以正常的框架都肯定有自动化处理这些过程的函数，直接调用就可以了。
知道了用户是哪一个，不能正确处理权限问题，那就是后端的锅。至于前端显示哪些菜单那完全是个显示问题而已。
--
FROM 101.88.159.*
你根本没了解需求
【 在 Madlee 的大作中提到: 】
: 简单说一下吧，这个技术至少30年前就已经很成熟了，也一点都不复杂。脑子正常的框
: 架都会采用，你非要选那些脑子不正常的那也确实没办法。
: 1. 使用https通讯，防止当中有人偷窥，这个没有什么好说的。
: 2. 登录过程，用户通过用户名/密码等等验证方式登录，登录成功，后端发一个随机数
: （学名session_id）给前端，前端要保存这个数到cookies里。后端会把这个随机数和你
: 登录的账户存到数据库/文件/redis里。由于前端只有这么个随机数，所以无法猜出和后
: 端用户的对应关系。
: ...................
--
FROM 120.229.207.*
那你可以重新阐述你的需求
如果需求是“安全”，上面给的建议基本都 中规中矩/至少不离谱
大家的建议集中在改造后端上这实际上就是一种共识，“前端是不靠谱的，不安全的，包括前端的代码”
【 在 iwannabe 的大作中提到: 】
: 你根本没了解需求
:
--
FROM 111.206.87.*
了解前后端分离的架构你就知道，所谓前端，某个功能就是访问一堆后端接口的集合。认
证后，通过jwt返回一个token，然后后续的接口访问都带上这个token来做认证。
你在本地启动一个前端，使用分配给你的普通权限账号，就和访问生产前端一样的效果。
但是某些功能权限的实现是通过屏蔽某些前端菜单来实现的，所以你可以通过修改前端来
访问这些隐藏的功能，当然在数据权限完备的情况下，你确实产生不了什么危害，但是仍
然可能存在安全隐患不是。
你可以想像自己这个前端是postman的接口集合。
这是chatgpt方案：
为了防止本地启动的前端代码访问生产环境的后端，可以考虑以下几种方案：
CORS（跨域资源共享）：通过在后端服务器上配置 CORS，只允许指定的前端域名来访问
后端接口。这样即使本地启动的前端代码想要访问生产环境的后端，也会因为跨域问题而
无法访问。
API 网关：将所有的后端接口都通过 API 网关暴露出去，并在 API 网关上设置访问控制
策略，只允许指定的前端域名来访问。这样即使本地启动的前端代码想要访问生产环境的
后端接口，也会被 API 网关拦截。
OAuth2：使用 OAuth2 认证授权框架，将前端和后端分别注册为不同的 OAuth2 客户端，
并且分别为它们分配不同的客户端 ID 和密钥。在 OAuth2 服务端上设置访问控制策略，
只允许使用正确的客户端 ID 和密钥来访问相应的后端接口。这样即使本地启动的前端代
码想要访问生产环境的后端接口，也需要正确的客户端 ID 和密钥才能访问。
【 在 hothail 的大作中提到: 】
: 那你可以重新阐述你的需求
: 如果需求是“安全”，上面给的建议基本都 中规中矩/至少不离谱
: 大家的建议集中在改造后端上这实际上就是一种共识，“前端是不靠谱的，不安全的，
: 包括前端的代码”
: ...................
--
FROM 119.139.198.*