Fork me on GitHub
#clojure-russia
<
2017-07-20
>
razum2um04:07:13

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

andrewtropin11:07:44

cider умеет

zarkone09:07:09

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

<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 прообовал так:
(boot/set-env!
   :repositories {"central"      ""
                  "local-base"   "file:///${basedir}/lib/"}
   :dependencies #(into % (deps category)))

но не помогло

andrewtropin11:07:50

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

andrewtropin11:07:00

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

misha13:07:15

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

misha13:07:57

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

andrewtropin14:07:14

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

misha15:07:02

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

misha15:07:20

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

misha15:07:08

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

dragoncube16:07:49

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

dragoncube16:07:14

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

niquola18:07:00

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