🙅‍♂️🙆‍♀️ VUE 3 Ролевая модель, ограничения доступов 

Привет! Спасибо за отклик! Я постараюсь, но со временем очень большая напряженка

Пожалуйста :) Но это не единственное решение и не сильвер булет, перед применением посмотри, возможно другие решение будут более подходящие :)

Спасибо! Надеюсь, весной снова смогу пилить видосы :)

Добрый день, приятно читать, спасибо!) Сейчас как раз изучаю 3 накст. Может быть когда вернусь - появятся видосы по нему :)

@@dev-workshop Было бы прям супер и полезнейше!)) Очень буду ждать, спасибо большое!!!

Ну вот здесь я бы поспорил) Возьмем TeamCity, явно не очень простое приложение или гитлаб В зависимости от разных доступов на одной странице в интерфейсе, даже в одной менюшке есть разный набор кнопок

@@dev-workshop я тут не прав в том смысле что слово "простые" тут не подходит. Ща попробую сформулировать точнее: если у вас интерфейс админа и юзера отличается целиком а не только лишь парой кнопок и менюшкой, то имеет смысл опереться о url ролевую модель. Это не подойдет лишь в случае если религия не позволяет наблюдать "/userRole/dashboard" в адресной строке. В остальном композиция компонент позволяет прекрасно переиспользовать код и не париться по поводу прав. Я не говорю что та модель которую вы рассмотрели не жизнеспособна, нет, она прекрасно работает но только в ряде случаев.

@@ESTechnonet Дополнив текущую реализацию можно сделать ограничения и по урлам, такми образом будет комбинированная система для накста очень удобно через pageMeta ограничивать доступы и мидлваркой их отлавливать

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

@@dev-workshop думаю все зависит от сценария. Я пилю щас crud saas и там например у каждого аккаунта рожаются роли и дефолтные пермишены. и если взять скажем роль админа который имеет доступ везде то там без групп получится что надо назначать простыню доступов на пару экранов) а если таких ролей будет несколько то все резко станет сложно) а так я завел группы и если юзер может все с crud сущностью то просто вешаю на нее группу. но в конце концов с бека оно конечно выпрямляется все и фронту прилетают только пермишены.

@@Dikodance интересное решение. Да, я скорее к тому, что с бека прилетал один тип сущностей, по которому определяются доступы. Для единообразия

Рад, что понравилось)

Пожалуйста:)

Спасибо! Добавлю в список идей для видео :)

Пожалуйста!)

Спасибо!) насчет provide/inject я отношусь к нему сильно хуже, потому что 1) не очень очевидно 2) нужно следить чтобы провайдер существовал в дом дереве, если провайдер лейаут и их несколько - начинается страдание 3) синтаксис и типизация немного страдают Я видел много боли, которую порождает provide/inject и видил мало проблем, которые он решает. В видео про аккордион, кстати, используется provide/inject По поводу разных пользователей - этот видос именно про авторизацию. метод fetchUserOnce как раз загружает информацию и скоупы для конкретного пользователя. ПОсле того, как прикручивается аутентификация, для каждого пользователя будут свои собственные скоупы. В видео я эмулировал это одним моком, но на бою для каждого свои скоупы

Пожалуйста :)

Спасибо!)

А какое продолжение ты ждешь?)

@@dev-workshop вроде было сказано что будет вторая часть с кастомной директорией

@@user-tm5ow3et4l А хочется именно с директивой? Или с компонентом? Или с супер злобной директивой?

@@dev-workshop с директивой лучше. с компонентом все понятно

Спасибо за идею!

Привет! Спасибо, в связи с работой сложно выделить время на видосики

Спасибо! 😉

Привет! Может быть если я найду того, кто будет монтировать видосы, тогда наладится регулярность ))

Спасибо!) Скоро будет еще :)

1. Полностью согласен, это была распространенная практика со 2 вью, в третьем она почти забыта 2. Такой задачи не стояло, видео и так объемное)

Ты все правильно говоришь. Однако: 1) Если имеем очень маленькие роли/скоупы/пермишены, их будет много. Чтобы применять их на пользователя нам не очень удобно делать это по одному и мы хотим их объединить в некоторые группы. Группа ролей? Иль роль с несколькими пермишенами/скоупами? В данном случае роли нужны только для удобства группировки пермишенов/скоупов. 2) Не совсем понял пример с моделями. На справочник для таблиц, в большинстве случаев достаточно иметь один скоуп - loggedIn так, как большой секретности, как правило, в справочниках нет. Конечно, чем больше логики, чем больше скоупов/пермишеннов/ролей тем сложнее кодовая база. Однако для веб приложений с ролевой системой, как правило, хватает 3-4 ролей и с ними 20-30 пермишеннов, это достаточно читаемо. Ну и конечно этот подход не лишен недостатков. Нужно критично относится к информации и анализировать, подойдет ли такой подход вам, или нет :) Этот подход подходит для меня в большинстве приложений с ролевой системой и я о нем рассказал :)

На бэке на C# в фреймворке такой же подход используется. Только там оно зовется Claims и также используется для раздачи точечных доступов, а подход с только с ролями типа админ , юзер считается уже устаревшим. Так что не утрируй, нормальный пример с раздачей мелких прав. Автору спасибо, за пример

Спасибо!)

Рад, что понравилось)

На самом деле можно оставить всю логику так как она есть вне зависимости есть стейт менеджер или его нет :) Если у вас нет ssr Если же есть сср, тут и логику поковырять нужно будет и думать как данные с сервера на клиент передать и как раз для этого можно воспользоваться стейт менеджером

Привет! Я очень рад, что тебе понравилось! Видео выходят не последовательно а как захочется что-нибудь рассказать :) Композиция помогла нам всем уйти от миксинов и других болей и принесла новые:) Когда-нибудь выйдет видео, в котором я расскажу как я пишу приложения без стора, разделив все на домены и сервисы. Но чуть позже :) P.S. мне опции нравятся больше, чем композиция и новая система реактивности, однако старые подходы имели проблемы с разделением ui и логики.

Буду дотягивать до «супер» :)

Здравствуйте, может быть ближе к лету, если найду редактора для видео

Скорее философский вопрос) Да, это будет кастомный v-if. Да, можно использовать просто v-if. Но идея директивы для доступов разделить условное отображение связанное с бизнес логикой и условное отображение связанное с ролевыми доступами Плюс по такой директиве легко прочитать доступы прям в шаблоне, тогда как условия v-if часто заворачиваются в компьютед свойства, для которых нужно лезть в код

Я согласен, но иногда от этого никуда не уйти)

Привет! Я не особо умею в PHP :( по этому скорее нет. Плюч видео сейчас временно не выходят

Рад, что видео понравилось! Такое ограничение точно должно быть известно бекенду, соответсвенно есть несколько вариантов: проставить флаг на беке, зашить поле scopes для каждого объекта на беке и докрутить логику на фронте, зашить эту логику на фронте, путём сравнения Id текущего пользователя и автора книги. У каждого способа есть свои плюсы и недостатки, нужно смотреть на конкретный проект

@@dev-workshop ещё вопрос. Сергей, почему scope, а не permission? Просто более короткая запись?

@@Markeldo Скорее вкусовщина) На моей первой работе были скоупы и я к ним привык)