API на F#. Доступ к модулям приложения на основе ролей

ASP.NET Core по стандарту предлагает настраивать доступ к api с помощью атрибутов, есть возможность ограничить доступ пользователям с определенным claim, можно определять политики и привязывать к контроллерам, создавая контроллеры для разных ролей
У этой системы есть минусы, самый большой в том, что смотря на этот атрибут:

[Authorize(Roles = "Administrator")] public class AdministrationController : Controller { }

Мы не получаем никакой информации о том, какими правами обладает администратор.

У меня стоит задача, вывести всех забаненных пользователей за этот месяц (не просто сходить в базу и отфильтровать, есть определенные правила подсчета, которые где-то есть), я делаю CTRL+N по проекту и ищу BannedUserHandler или IHasInfoAbounBannedUser или GetBannedUsersForAdmin.

Я нахожу контроллеры, помеченные атрибутом [Authorize(Roles = «Administrator»)], тут может быть два сценария:

Делаем все в контроллере

    [Route("api/[controller]/[action]")]     public class AdminInfoController1 : ControllerBase     {         private readonly IGetUserInfoService _getInfoAboutActiveUsers;         private readonly ICanBanUserService _banUserService;         private readonly ICanRemoveBanUserService _removeBanUserService;          // зависимости нужны нескольким action         public AdminInfoController1(             IGetUserInfoService infoAboutActiveUsers,             ICanBanUserService banUserService,             ICanRemoveBanUserService removeBanUserService)         {             _getInfoAboutActiveUsers = infoAboutActiveUsers;             _banUserService = banUserService;             _removeBanUserService = removeBanUserService;         }          // actions         //...         //...     }

Разносим по хендлерам

    [Route("api/[controller]/[action]")]     public class AdminInfoController2 : ControllerBase     {         [HttpPatch("{id}")]         public async Task<ActionResult<BanUserResult>> BanUser(             [FromServices] IAsyncHandler<UserId, BanUserResult> handler,             UserId userId)               => await handler.Handle(userId, HttpContext.RequestAborted);          [HttpPatch("{id}")]         public async Task<ActionResult<RemoveBanUserResult>> RemoveBanUser(             [FromServices] IAsyncHandler<UserId, RemoveBanUserResult> handler,             UserId userId)              => await handler.Handle(userId, HttpContext.RequestAborted);     }

Первый подход неплох тем, что нам известно доступ к каким ресурсам имеет Админ, какие зависимости он может использовать, я бы использовал такой подход в маленьких приложениях, без сложной предметной области

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

У всего этого есть большой недостаток, код не говорит разработчику что делать, заставляет задумываться => трата времени => ошибки в реализации

А чем больше приходится думать, тем больше совершается ошибок.

Введение в маршрутизацию Suave

Что если routing будет строиться так:

let webPart =         choose [             path "/" >=> (OK "Home")             path "/about" >=> (OK "About")           path "/articles" >=> (OK "List of articles")           path "/articles/browse" >=> (OK "Browse articles")           path "/articles/details" >=> (OK "Content of an article")       ]   

»>=>» — что это? У этой штуки есть название, но его знание ни на грамм не приблизит читателя к пониманию, как это работает, поэтому приводить его нет смысла, лучше рассмотрим, как все работает

Выше написан pipeline от Suave, такой же используется в Giraffe (с другой сигнатурой функций), есть сигнатура:

type WebPart = HttpContext -> Async<HttpContext option>

Async в данном случае не играет особой роли(чтобы понять как это работает), опустим его

HttpContext -> HttpContext option

Функция с такой сигнатурой принимает HttpContext, обрабатывает (десериализует тело, смотрит на куки, заголовки реквеста), формирует ответ, и если все прошло успешно — оборачивает в Some, если что-то не так, возвращает None, например (библиотечная функция):

  // дополнительно оборачиваем в async   let OK s : WebPart =     fun ctx ->            { ctx with response =                { ctx.response with status = HTTP_200.status; content = Bytes s }}            |> Some |> async.Return

Эта функция не может «завернуть поток выполнения запроса», всегда прокидывает дальше новый response, с телом и статусом 200, а вот эта может:

let path (str:string) ctx =             let path = ctx.request.rawPath             if path.StartsWith str              then ctx |> Some |> async.Return             else async.Return None 

Последняя нужная функция это choose — получает список различных функций и выбирает ту, которая первая вернет Some:

let rec choose   (webparts:(HttpContext) -> Async<HttpContext option>) list)  context=               async{              match webparts with                         | [head] -> return! head context                         | head::tail  ->                              let! result = head context                             match result with                             | Some _-> return result                             | None -> return! choose tail context                         | [] -> return None              }

Ну и самая главная, связывающая функция (Async опущен):

type WebPartWithoutAsync = HttpContext -> HttpContext option let (>=>) (h1:WebPartWithoutAsync ) (h2:WebPartWithoutAsync) ctx                                      : HttpContext option =  let result = h1 ctx  match result with   | Some ctx' -> h2 ctx'   | None -> None

type WebPart = HttpContext -> Async<HttpContext option> let (>=>) (h1:WebPart ) (h2:WebPart ) ctx : Async<HttpContext option>=   async{    let! result = h1 ctx    match result with     | Some ctx' -> return! h2 ctx'     | None -> return None   } 

«>=>» принимает два хендлера с левой и правой сторон и httpContext, когда приходит запрос, сервер формирует объект HttpContext, и передает его функции, «>=>» выполняет первый(левый) хендлер, если он вернул Some ctx, передает ctx на вход второму хендлеру.

А почему мы можем писать так (комбинировать несколько функций)?

GET >=> path "/api" >=> OK

Потому что «>=>» принимает две функции WebPart и возвращает одну функцию принимающую HttpContext и возвращающую Async<HttpContext option>, а какая функция принимает контекст и возвращает Async<HttpContext option>?
WebPart.

Получается что «>=>» принимает для хендлера WebPart и возвращает WebPart, поэтому мы можем написать несколько комбинаторов подряд, а не только два.
Подробности о работе комбинаторов можно найти здесь

При чем тут роли и ограничение доступа?

Вернемся к началу статьи, как можно явно указать программисту, к каким ресурсам возможен доступ для той или иной роли? Нужно внести в pipeline эти данные, чтобы хендлеры имели доступ к соответствующим ресурсам, я сделал это так:

Приложение разделяется на части/модули. В функциях AdminPart и AccountPart разрешается доступ к этим модулям различных ролей, к AccountPart имеют доступ все пользователи, к AdminPart только админ, происходит получение данных, обратите внимание на функцию chooseP, я вынужден добавить еще функции, потому что стандартные привязаны к типам Suave, а теперь у хендлеров внутри AdminPart и AccountPart другие сигнатуры:

// AdminPart    AdminInfo * HttpContext -> Async<(AdminInfo * HttpContext) option> // AccountPart     AccountInfo* HttpContext -> Async<(AccountInfo * HttpContext) option>

Внутри новые функции абсолютно идентичны оригинальным

Теперь хендлер сразу имеет доступ к ресурсам для каждой роли, туда нужно добавить только основное, чтобы можно было легко ориентироваться, например в AccountPart можно добавить никнейм, email, роль пользователя, список друзей если это соц.сеть, но возникает проблема: для одного подавляющего большинства хендлеров мне нужен список друзей, но для оставшихся он вообще не нужен, что делать? Либо разнести эти хендлеры по разным модулям(желательно), либо сделать доступ ленивым(обернуть в unit -> friends list), главное не класть туда IQueryable<Friend>, потому это не сервис — это набор данных, определяющий роль

Я положил в AdminInfo информацию об одобренных и забаненных пользователях текущим админом, в контексте моего «приложения» это определяет роль Администратора:

   type AdminInfo = {             ActiveUsersEmails: string list             BanUsersEmails : string list                           }     type UserInfo = {             Name:string             Surname:string         }

В чем отличие от Claim? Можно же в контроллере сделать User.Claims и достать то же самое?

В типизации и в «говорящих»: модулях, разработчик не должен искать примеры кода по хендлерам, находящимся в том же контексте, он создает хендлер и добавляет в роутинг и заставляет все это компилироваться

let AccountPart handler =              let getUserInfo ctx =                  async.Return {Name="Al";Surname="Pacino"}             permissionHandler [User;Admin] getUserInfo  handler

getUserInfo получает данные для модуля Account, имеет доступ к контексту, чтобы достать персональные данные(именно этого user’a, admin’a)

permissionHandler проверяет наличие jwt token’a, расшифровывает его, и проверяет доступ, возвращает оригинальный WebPart, чтобы сохранить совместимость с Suave

Полный исходный код можно найти на github
Спасибо за внимание!