RESTful Широ разрешения на основе данных - PullRequest
1 голос
/ 28 марта 2019

Я создаю службу RESTful с Джерси (2.28) и использую Apache Shiro для обработки разрешений.Поэтому я использовал buildin HttpMethodPermissionFilter, который создает разрешения типа resource:read или resource:write.Теперь у меня проблема в том, что пользователю может быть разрешено только читать или писать определенный ресурс, и мне нужно что-то вроде resource:write:<id> или resource:write:<name> или что-то еще в качестве идентификатора.

Я думал о расширении фильтра, но на этом этапе - даже когда я мог получить доступ к телу или URL-адресу - у меня нет понятия , как выглядят данные.

Решения, о которых я думал:

  1. Всегда передавайте параметр запроса в URL-адресе, например /api/resource?id=xxx, и, если он указан, применяйте этот параметр для строки разрешений.Но невозможно определить, является ли параметр обязательным или нет, если существуют и resource:read, и resource:read:<id>.Фильтр может создать неправильное разрешение для данного URL.Я мог бы применить фильтр только к URL-адресам, где я знаю, что это должно быть так, но кажется все немного вялым и подверженным ошибкам.

  2. Снимите фильтр и запросите разрешения внутри запрашиваемого метода.

@GET
@Path("/resource/{id}")
public Response getResource(@PathParam("id") String id) {
    if(AuthorizationHandler.hasPermission("resource:read:" + id) {
        return Response.status(Status.OK).entity("Resource GET works").build();
    } 
    // return 403 or handle exception or ...
}

В некотором роде, но это меня оставитс обработкой исключений в каждом методе, который также кажется не слишком предпочтительным.Возможно, я мог бы использовать ExceptionMapper для обработки ответов ... еще не пробовал.

Может быть, у кого-то есть еще идеи, как решить эту проблему эффективно, или, может быть, укажете мне на уже существующее решение?Я бы предпочел использовать аннотацию @RequiresPermissions("resource:read") (или пользовательскую), но также мог бы определить URL-адреса / фильтры в файле shiro.ini /api/resource/** = noSessionCreation, jwtf, rest[resource], или я могу вернуться к решению 2, если это рекомендуется.

...