本文是《Solo 从设计到实现》的一个章节,该系列文章将介绍 Solo 这款 Java 博客系统是如何从无到有的,希望大家能通过它对 Solo 从设计到实现有个直观地了解、能为想参与贡献的人介绍清楚项目,也希望能为给重复发明重新定义博客系统的人做个参考 ❤️

权限校验

之前在登录会话的章节我们介绍过如何判断是否登录,解决了身份认证(Authentication),另外还有一部分是功能授权(Authorization)。

ConsoleAuthAdvice.java 中判断是否登录后还进行了角色判断:

if (!userQueryService.isLoggedIn(request, context.getResponse())) {
    final JSONObject exception401 = new JSONObject();
    exception401.put(Keys.MSG, "Unauthorized to request [" + request.getRequestURI() + "]");
    exception401.put(Keys.STATUS_CODE, HttpServletResponse.SC_UNAUTHORIZED);

    throw new RequestProcessAdviceException(exception401);
}

final JSONObject currentUser = userQueryService.getCurrentUser(request);
final String userRole = currentUser.optString(User.USER_ROLE);
if (Role.VISITOR_ROLE.equals(userRole)) {
    final JSONObject exception403 = new JSONObject();
    exception403.put(Keys.MSG, "Forbidden to request [" + request.getRequestURI() + "]");
    exception403.put(Keys.STATUS_CODE, HttpServletResponse.SC_FORBIDDEN);

    throw new RequestProcessAdviceException(exception403);
}

通过 HTTP 状态码进行了异常情况的细分:

  • 401:未登录
  • 403:登录了,但是权限不足

有意思的是 401 常规返回的消息是“Unauthorized”,实际上它指的是 Unauthenticated。这两个状态码的差异细节可参考 SO 讨论 403 Forbidden vs 401 Unauthorized HTTP responses

XSS

访客可输入的地方在前台只有一个,就是发布评论。所以防 XSS 主要就是防止评论内容带 XSS。后台不存在这个问题,因为后台很多地方都是允许设置脚本的,比如文章内容、公告栏等。

对 XSS 处理我们是放在获取评论的时候,在访客发布评论的时候并没有进行过滤。也就是说,数据库里保存的评论正文是可能带有攻击脚本的原文。这样设计的好处是如果发生了之前未知的安全过滤问题,在新版本升级后不用更新已有数据。

CSRF

目前暂时没有进行处理,后续可能会改进。


回到全文目录:《Solo 从设计到实现》

感谢    关注    收藏    赞同    反对    举报    分享