怎样避免已登陆的用户修改不应该由他操作的数据(具体看描述)?

UncleBen 发布于 2016/09/28 17:19
阅读 384
收藏 1

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

    例如,前端可以发起请求 http:xxx.com/deleteById/id=xxx,已登陆的用户知道这个接口,向这个接口发起请求,删除了不应该由自己操作的数据,怎样避免这种情况?

    现在的思路有:1,在 SQL 语句加上条件 WHERE userId = 当前用户的id,操作的数据有个字段为
userId,缺点就是使用 Hibernate的话,更新操作,删除操作 就不能调用session.update(),session.delete(),需要自己写;2,检测操作的数据的 userId 是否等于当前用户的 id,显然前者比较好;

    有没有别的更好的办法?

    希望知道的站友能支招,先谢了。

加载中
0
高山流水情
高山流水情

建议按第二种方式做。

我们把类似的这些验证都归为业务验证。例如记录是否是当前用户所有、记录是否存在、记录的状态是否变化...。严格一点,每个后台action方法中都需要做这些验证。


UncleBen
UncleBen
谢谢您的回答,您说得很有道理。
0
kurumi
kurumi
就按第一个思路做咯,框架倒成限制你的条件了
0
就是个精虫上脑的地方
就是个精虫上脑的地方
在条件里把用户组或者ID带上 
0
lieefu
lieefu
除了从技术上在服务端加判断,当前用户是否有权删除这条数据外,还有个思路就是从制度上限制,这样后台增加删除记录的日志功能,由业务制度规定,谁越权删除数据,惩罚谁。
osc_249693
osc_249693
这个好,以后就可以以违背价值观开人!
0
伊人梦醉
伊人梦醉

没理解你这个是什么意思。。。

既然是开放的接口那就是可以调用的啊,只是可能存在权限的问题!如果你是说http:xxx.com/deleteById/id=xxx,用户只能删除属于自己的数据的话那就是条件上必须要加上用户的限制。

UncleBen
UncleBen
对,的确是权限问题,两个用户同级,都可以删除订单,订单也是标记了属于哪个用户操作的,描述中的第二个思路就是判断要删除的订单是否属于正在操作的用户,但是如果程序加判断,就是要查数据库,如果是批量的删除,就会出现性能问题(因为可能要查很多次),为了避免这种问题,可以依据问题描述中的第一个思路来做,我就是想问问有没有更好的做法,谢谢您的回答。
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部