есть вариант прогонять с clojure.test только зафейленные в прошлый раз vars?

@razum2um Вот это умеет: https://github.com/jakemcc/lein-test-refresh

CIDER тоже: https://cider.readthedocs.io/en/latest/running_tests/

всем привет) кто-нибудь добавлял в буте путь к локальным либам мавена? в мавене это вот так прописывается:

<repositories>
        <repository>
            <id>3rd-party-local-repo</id>
            <name>This is a local repository included in the grobid project, to access 3rd party libs.</name>
            <url>file:///${basedir}/lib/</url>
            <layout>default</layout>
        </repository>
...
</repositories>

(boot/set-env!
   :repositories {"central"      ""
                  "local-base"   "file:///${basedir}/lib/"}
   :dependencies #(into % (deps category)))

Расскажите пожалуйста как делать авторизацию в RESTапишке, если у меня доступ к методу ресурса зависит от нескольких параметров (принадлежит ли пользователь организации, автор ли он этого объекта и т.д.)

Из интересного пока нашли [ABAC](https://en.wikipedia.org/wiki/Attribute-based_access_control) и [clara rules](http://www.clara-rules.org/). Пока всё равно не понятно, как написать гибкий механизм авторизации.

https://medium.com/@niquola/access-control-model-for-fhir-generic-server-dd66deb7cae6

@andrewtropin а в чем именно для вас сложность заключается?

"чем именно не подходит громадный ветвистый if/case?"

На данный момент есть куча разных функций типа user-can-view? user-can-edit? user-is-manager? и т.д. Они размазаны в разных эндпоинтах в разном количестве, это работает, но выглядит костыльно и у них разный контекст, поэтому они принимают разные параметры, который нужно не забыть прокинуть. На данный момент кажется, что стоит всю логику авторизации вынести в одно место и оставить одну функцию (defn is-authorized? [context] ...) и дёргать эту функцию в какой-нибудь мидлвари. Возникает вопрос как собирать этот контекст, как по контексту понимать что из базы надо посмотреть и т.д. Ещё небольшая проблема, что в мидлварь приходит сырой запрос, без coercion. И да, как писать логику авторизации тоже не до конца понятно, тонна ифов будет выглядеть паршиво и нечитабельно. Матчеры урлов по регэкспам делать, а потом уже смотреть на контекст и дотягивать нужные данные с помощью нужной функции?, тогда можно было бы хранить всё это в хэшмапе или как-то ещё. А не будут ли эти регэкспы повторять структуру роутов? Кажется хочется какой-то декларативности в правилах авторизации. Пока вопросов больше, чем ответов. Живых примеров не нашёл, из интересного декларативного только клару.

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

зато, когда становится понятно что и откуда, например "мидлварю напишем", – клара выгоднее чем ифочка, потому что она открытая система, как мультиметод что ли, в которую можно из разных мест, и в разное время напихивать факты

но чуваки из клары мне сказали, что для задач типа "стейт большого компонента для сингл пейдж апликейшена" - непосредственно клара - оверкил

@nicola а вы GraphQL не используете?

как там делать RBAC/ACL ?

GQL лежит в бэклоге - с контролем доступа там будет наверно сложновасто, пока не думал 🙂 была безумная идея использовать https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html