[paused] stage 1: Auth / RBAC

[atherdon]

tags & keywords это скорее фича, чем чтото важное сейчас. но т.к там ничего сложного тоже нет - можно и их перенести. просто в тот момент, когда мы сделаем деплой и девы смогут фетчить данные - нам tags\keywords погоды сейчас не делают. тоже самое и с progress.

---

нужно понять как перекинуть первые данные фронтенд девелоперам, чтобы они могли убить у себя ту папку data. заодно они могут написать список с calcualtions, которые нам чуть позже понадобится сделать, чтобы данные просто статикой выводились внутри таблиц.

---

stage 1: authentification: to be discussed - simple for 10 ppl or RBAC with 2-3 roles

Наши основные разработчики, которые делают весь проект - немного скептически относятся к тому, что я посути решил убить их код и начать все с нуля. причина простая - они поддерживают сложный проект и на изменения админки у них нету времени. плюс админка это скучно. Поэтому когда я им начал показывать наш код - они сразу смогли меня уколоть, сказав что проект сейчас не очень секьюрный. с чем я согласен - но это не была основная проблема.
С другой стороны - раз уж мы начали разбивать проект, которому 2 месяца уже на две части - может нам стоит сразу предусмотреть auth и rbac.

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

с другой стороны - если делать нормальный RBAC - скорее всего кастомный вариант лучше. посути у нас не будет много польвателей, кому нужен доступ к админке. ну 8 редакторов. ну допустим еще сделаем каждому разрабочику по аккаунут чтобы они могли тестить. в общем вопрос интересный, но сейчас он в low priority - потому что отдельный backend отодвигает запуск этого проекта немного назад.

[kolserdav]

Для фронтенда достаточно файлов docs/API.md и постман коллекции в resources/postman.

[atherdon]

Давайте тогда обсудим как мы должны сделать auth. поидее, оба варианта(simple auth & rbac) уже реализовывали на graphql и не раз. поэтому мы можем попробывать или адаптировать чужой код или сделать свою версию.
я конечно за то чтобы оптимизировать чужую схему - чтобы было проще.

для текущей версии проекта - auth который позволит работать внутри 10 людям - полностью удовлетворяет текущий scope. с другой стороны - тк мы начинаем с чистого листа - возможно расширенная версия не займет так много времени как мне кажется.

нужно ваше мнение @kolserdav

ссылки которые я быстро нагуглил

• https://graphql.org/learn/authorization/
• https://github.com/kkemple/graphql-auth

rbac

• https://medium.com/swlh/rule-based-authorisation-for-your-graphql-server-cf81bfa60790
• https://github.com/Canner/graphql-rbac
• https://auth0.com/blog/dynamic-authorization-with-graphql-and-rules/

[kolserdav]

* https://github.com/kkemple/graphql-auth

В версии 3.3.0 использовал опыт создания хука из https://github.com/kkemple/graphql-auth, отказавшись от небезопасного посредника на уровне express. @atherdon спасибо)

Теперь можно закрывать роуты:

• по минимальной роли
• по определённым ролям
• разрешать доступ к своим материалам независимо от двух предыщих ограничений
• запрещать изменение определенных полей, при доступе по предыдущему пункту, если один из первых двух не разрешает

Управляется просто, при объявлении резолвера используется хук withAuth, код для добавления дополнительных правил доступа к своим материалам вынесен в отдельный файл graphq/checkSelfSchema.ts

[atherdon]

Вынес этот комментарий в отдельный таск - потом когда будем роли подключать в dashb - сразу понадобится.

нужно ли мне сделать список ролей, чтобы вы их залили в базу сразу? я могу сделать обычный js array и добавить его в папку data - на будущее cc @kolserdav

[kolserdav]

Сейчас роли это просто integer где 0 - простой юзер. Ограничений нет по количеству ролей. Можно и именовать их, но тогда нужна их нумерация для закрытия по минимальной роли, если оно планируется на будущее.

[atherdon]

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

[kolserdav]

Как реализовать посредника это детали. Главный вопрос как хранить сессии. Знаю два варианта.

1. Без хранения в базе. jsonwebtoken - шифрует по секретному ключу ид пользователя, и часть хеша пароля (чтобы блокировать если пароль был изменен).
2. Auth token - уникальная строка хранящаяся в базе или в Redis.
   В первом случае можно сделать постоянный токен так как ответственность за его сохранность лежит на самом пользователе, а во втором естесственно только по времени жизни токена и каждый запрос обновлять время.

[atherdon]

я могу рассказать детали, а вы уже примете решение:

1. Нам важно делать быстро проект, поэтому я даже бекенд вначале не хотел создать

2. Думаю что для начала мне на секьюрити наплевать, потому что пока мы используем старую дашбоард - компания просто теряет больше денег.

3. Возможно нам лучше сделать импорт а потом думать про аутентификацию.

4. Если вы смогли затащить ещё мелкий проект - это бы сьекономило мне время и я смог бы сделать нормальное описание какие схемы нам нужно сделать.

5. Проект наш будет переделываться несколько раз, текущая версия не должна быть идеальной. Потому что через месяца 2-3 нам придется коннектится к основному ядру проекта, а какой там код внутри я не знаю

[kolserdav]

Получается, нужно сделать, регистрацию, аутентификацию, и встроить https://github.com/kkemple/graphql-auth или найти другое решение для авторизации, и закрыть несколько узлов для примера?

[atherdon]

Получается, нужно сделать, регистрацию, аутентификацию, и встроить https://github.com/kkemple/graphql-auth или найти другое решение для авторизации, и закрыть несколько узлов для примера?

Думаю да. мне кажется этого нам хватит. А если уже возникнет вопрос в том что нужно расширить функционал - у prisma хорошо сделан процесс апдейтов схем.

[atherdon]

@kolserdav я на всякий создам проект по stage 1 react-auth, а условия мы всегда сможем изменить. просто нехочу вас тормозить со своей стороны

[atherdon]

не удержался

[kolserdav]

"можно было прикрутить какой то oauth0 например и забыть об этом"

Oauth это если у вас есть сервер с реализованной авторизацией, то можно перенаправлять туда там авторизуется оттудв присылается временный одноразовый токен по которому можно получить его публичные данные. На сервере нужно чтобы проверял document.referer при заходе на страницу авторизации и query string с ид запроса и в случае успеха если всё сходится перенаправлять на страницу с токеном и ид запроса в uri.

Если рассматривать Oauth популярных сервисов, то нужно чтобы сервис соответствовал их требованиям в плане бизнес правил интернета.

[kolserdav]

"с другой стороны - если делать нормальный RBAC "

Если auth реализован, rbac это просто название роли в профиле поьзователя и описание их уровней плюс один if в посреднике, который сверяет минимально допустимую роль контекста с ролью пользователя. Или точное совпадение, если допуск к контексту не по range а по equal или enum.

[kolserdav]

По авторизации, сложности испытал с графкл(, не стал костыли лепить, лишь бы сделать, на завтра перенес, подумать надо.

[atherdon]

это хорошо что застряли немного - значит начинается интересная часть

[kolserdav]

У меня кончается триал на auth0, с формами закончу, продолжу с ним разбираться, уже в рамках фри аккаунта.

[atherdon]

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

…

[kolserdav]

И root сервера и sudo не давать чужим, иначе может просто отключить аутентификацию сервера базы и залезть куда не следует)

[kolserdav]

Если всё это сделать, то цена получения этих емайлов будет в тысячи раз больше их номинальной стоимости.

[kolserdav]

Я не хочу вас торопить, просто хотел убедится, что Вы помните про stage1.

[atherdon]

я пока еще не придумал как решить этот вопрос :)

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

[kolserdav]

Не вопрос:) Просто, возможно мои наводящие вопросы смогут вам пригодиться.
Когда будете по этому вопросу принимать решение, предлагаю сначала попробовать набросать какие запросы кому будут разрешены, а какие кому нет. А от этой политики уже отталкиваться на каком инструменте реализовывать.

[atherdon]

Я как раз очень рад тому что мы обсуждаем эти stages. потому что в итоге получается даже лучше чем было задумано.

[atherdon]

Я все надеюсь на то что когда мы выкатим крутые изменения в Апреле - основные девы охренеют и может сами напилят auth :) Но они оч заняты. поэтому я только им рассказываю, но ничего не показываю