场景模拟
-
场景一
只允许资源的所有者才能对资源进行操作（CRUD）。比如，jack在某博客平台写了一篇私密文章，只有自己可以对这篇文章进行增删查改的操作；
-
场景二
允许指定个人或者角色也能对资源进行操作。比如，jack邀请他的好朋友mason对文章进行查看和修改；
方案一
最简单和最直接的就是，在web层接收到操作请求后，在执行这个操作前，对请求的合法性进行校验。比如，查询当前需要操作的资源是否归属当前session中的已登录用户；或者查询当前需要操作的资源是否是允许操作的其它用户。
String loginUser = session.get("username");
// 增加水平越权校验
if(!checkAuthority(loginUser,articleId)){
return false;
}
// 执行正常的操作
// 当前登录者是否是资源的所有者
private Boolean checkAuthority(String loginUser, String articleId){
String articleOwner = articleService.getOwner(articleId);
return Objects.equals(loginUser, articleOwner);
}
// 当前登录者是否有操作权限
private Boolean checkAuthority(String loginUser, String articleId){
int count = articleService.getLegalUser(loginUser, articleId);
return count > 0 ? Boolean.TRUE : Boolean.FALSE;
}
这种方案的优点是实现简单，逻辑清晰；但是缺点也很明显，需要对每一个请求都加上这种操作，很是繁琐，而且多了一次数据库查询，效率肯定有所下降；
方案二
我们可以直接将登录者的信息传递到SQL层面进行校验，比如场景一我们可以在原SQL最后加上一句来限制资源的操作。
select * from artile where article_id = #{articleId}
and author = #{loginUser}
如果是场景二的话，我们需要多关联一张表。
select * from artile a join author_guest g on a.author = g.author where article_id = #{articleId}
and g.guest = #{loginUser}
其中author_guest存放的是作者邀请的朋友之间的关系映射表。
这种方案的优点是没有增加额外的Java代码，没有增加额外的数据库查询，比较简洁优雅；但是缺点是需要改动SQL，增加了SQL的复杂性，而且有时一个SQL是供多块逻辑共用的，A模块需要鉴权，B模块不需要鉴权，那就要重新写一份相同的SQL或者在SQL上加分支了，那SQL会变得更难以理解和维护。
除此之外，好像还没法区分没有数据和没有权限两种操作异常情况，只能给前端反馈操作异常的提示，不是很友好。
