2

这个问题可能带有一点哲学意味。

我一直在我的 Play 应用程序中使用 Deadbolt 2 (Scala)，它运行良好。

在查看Restrict 函数定义（第 47 行）时，我注意到它会出于以下原因之一调用 onAuthFailure：

  1. 会话中没有用户（没有主题）
  2. 操作未指定角色。
  3. 用户尝试了他们不具备一个或多个所需角色的操作。

在我的应用程序 UI 中，我希望为每一个接收一个不同的状态代码，以便未登录的用户（条件 1）将被重定向到登录页面，但条件 3 将通过警告更优雅地处理（因为他们无论如何都不会造成伤害，并且可能在他们具有“只读”访问权限时不小心尝试编辑 - 可能是一个 UI 错误，但再次登录有点苛刻）。

但是，如果我只能满足于 2 个状态代码，我会想区分 1 和其他 2。我可以看到如何实现，但想就即使这样做的优点获得其他意见。

如果我要实现此更改，看起来我可以在我自己的 DeadboltActions 特征扩展中覆盖 Restrict 函数。

我对 scala 有点陌生，所以我对如何最好地实现这些目标的其他想法持开放态度。

4

1 回答 1

0

我决定只添加代码来区分条件 1 和 2 或 3，如下所示：

在 MyDeadboltHandler 中：

class MyDeadboltHandler(dynamicResourceHandler: Option[DynamicResourceHandler] = None) extends DeadboltHandler {
...
  def onAuthFailure[A](request: Request[A]): Result = {
    Logger.error("authentication failure")
    val json = new JsonStatus("Failed to authenticate", -1).toJson.toString
    if(noUserInSession(request)){
      Results.Forbidden(json).withHeaders("Access-Control-Allow-Origin" -> "*")
    }
    else{
      Results.Unauthorized (json).withHeaders("Access-Control-Allow-Origin" -> "*")
    }
  }

  def noUserInSession(request:RequestHeader) = {
    username(request) match {
      case Some(u:String) => false
      case _ => true
    }
  }

这对我来说效果很好，不会强加于基本的 Deadbolt-2 功能。

于 2014-12-14T22:28:06.103 回答