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

[@Screxyy]

Посмотрев это видео, понял сколько мне еще учиться xDD

[@r35p3ct00]

Пора выпускать ролик 😁

[@Dikodance]

Эх, где это видео было раньше. Столько времени убил чтоб самому допереть до этого)) спасибо. Ещё удобно добавить группы скоупов, особенно если из много и юзеры сами будут рулить доступами

[@dev-workshop]

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

[@Dikodance]

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

[@dev-workshop]

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

[@kalyszhek5296]

Ты мне открыл глаза. 😳🥹 Но я нифига не понял, но к этому иду. Я начинающий. 😅 Пойду посмотрю все видео. Надеюсь есть где пишешь все это..

[@K1appy]

офигенный контент, пожалуйста не забрасывай канал, очень полезные видео, а не просто пересказ доков или объяснения как через v-for список вывести !

[@dev-workshop]

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

[@ESTechnonet]

Самый имбовый способ разделить роли - разные url для разных ролей. Все остальное (в том числе то, о чем говорит автор) для очень простых приложух.

[@dev-workshop]

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

[@ESTechnonet]

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

[@dev-workshop]

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

[@jonyonee]

Блин классно, в каком то периоде это точно мне понадобится. Спасибо большое.

[@dev-workshop]

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

[@grigoriy-iceicebaby2985]

Классный контент, помогает, продолжение этой части с тайпскриптом нужно!

[@mikhailwalle9556]

Ждем новых видео. У тебя очень годный материал!

[@dev-workshop]

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

[@antonnevskiy3027]

Полезное видео, спасибо! Жаль, не так много контента на канале

[@dev-workshop]

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

[@user-quasarDiO]

Крутая тема , давай продолжение , видео понравилось !!!

[@TheHaykokalipsis]

Красава, давно ищю нечто подобное, жаль тайпскрипт не понимаю. Ждём продолжения с компонентом и директивой.

[@dev-workshop]

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

[@fluffyartdev]

Видео полезное, для новичком будет очень здорово, но есть пара нюансов: 1. Глобальный скоуп работает только в рамках шаблона. В скрипте все равно придется доставать хуком или еще как-либо. 2. В данном случае, хоть сама задача авторизации и является глобальной, все таки стоит еще задуматься о том, чтобы сделать хуки импортить от туда хук + енам. Тем более, если делать директиву или компонент обертку, то это уже не выглядит таким накладным)

[@dev-workshop]

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

[@АлександрСударев-ж1г]

Спасибо! Очень круто!!!!

[@dev-workshop]

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

[@tatianovnafrutti8982]

Супер! Спасибо за крутейший контент!!! Очень помогаете) Было бы круто увидеть какой-нибудь мини курс или туториал , так сказать --- разработка небольшого приложения с применение Vue + MongoDB + Express. А еще может GraphQL + Apollo , было тогда вообще бомба! Или заместо Vue , использовать Nuxt 3. Очень помогли бы)

[@dev-workshop]

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

[@tatianovnafrutti8982]

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

[@amir18n]

Спасибо! полезные знания

[@dev-workshop]

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

[@ruslan_nurgaleev]

Спасибо, очень полезное видео

[@dev-workshop]

Спасибо!)

[@andreymor_ozzy8143]

Спасибо, жду продолжение видео

[@dev-workshop]

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

[@IvanKuznecov-n6v]

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

[@dev-workshop]

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

[@ulyanov_life]

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

[@katana_yaiba]

Спасибо большое, очень полезное и интересное видео с новым для меня подходом!

[@dev-workshop]

Спасибо! 😉

[@technews2324]

Спасибо!

[@dev-workshop]

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

[@Xokyopo]

Если посмотреть пристально то это просто роли ролей. А следовательно не так уж и необходимы. Т.е. ничто не мешает завести ROLE_BOOK_READER и их назначать пользователям. Так же такой подход рухнет если много разных моделей. Например на 1 таблицу только для ее просмотра потребуется 3 модели, и по факту для каждой из них придется свою роль завалить. А 3 потому что 1 полная, 2 умеренная, 3 справочник для подстановки.

[@dev-workshop]

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

[@zergzerg4844]

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

[@Vladislav1449]

Привет! Очень жаль, что видео перестали выходить довольно продолжительное время😢 Надеюсь, еще появится тут новый, полезный контент!❤

[@dev-workshop]

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

[@ulyanov_life]

Спасибо за видео, Серег! Предлагаю тему для нового видео: моки для фронта. можно раскрыть разные варианты с плюсами и минусами.

[@dev-workshop]

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

[@YellowPanamka]

Спасибо

[@dev-workshop]

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

[@akad1981]

Доступно. Полезно. Ждем продолжения.

[@dev-workshop]

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

[@surr3955]

Спасибо за то, что делишся опытом! 16:00 как насчёт provide/inject? И конешно мы все ждём продолжения про дерективу v-scope! И еще было бы интересно, как реализовать авторизацию нескольких аккаунтов (с разными правами) и переключение между ними.

[@dev-workshop]

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

[@flipper-limon]

Написал комментарий) где видео с кастомной директивоЙ?

[@БехрузАбдувалиев-н5и]

🔥🔥🔥

[@vegeman8954]

Прикольно. Продолжай бро!)

[@dev-workshop]

Спасибо!)

[@grantorino3465]

Огонь!

[@dev-workshop]

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

[@mikhailwalle9556]

Буду чертовски благодарен, если прокомментируешь данную логику в контексте приложения с стейт менеджером (Pinia, Vuex).

[@dev-workshop]

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

[@АртемАртеменконезабывайвыходит]

сделаешь подробнее уроки с vue laravel по этой теме?

[@dev-workshop]

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

[@adiletomurbekov9300]

Здравствуйте, можете сделать пожалуйста видео про авторизацию.

[@dev-workshop]

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

[@izzy7541]

А нужна ли вообще директива для доступов? По моему получится велосипед в виде кастомного v-if

[@dev-workshop]

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

[@Denchenity]

Супер круто, посмотрел все видео) всё-таки интересует вопрос.. почему композиция, а не опции? И будут ли видео по композиции. Хотя судя по видео, это уже пройденная тема))

[@dev-workshop]

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

[@Markeldo]

Спасибо за видео, было полезно. Есть вопросик такой... А как решать проблему доступа к определённым объектам? Допустим, мы даём удалять книгу только тому, кто её создал. При этом всем пользователям видны все книги. Пытался продумать это в рамках этих скоупов, но что-то "не выходит каменный цветок".

[@dev-workshop]

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

[@Markeldo]

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

[@dev-workshop]

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

[@xeleos]

Неплохо!

[@dev-workshop]

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

[@shahid1508]

Динамические группы/роли/скоупы то еще зло на деле, хоть и звучит красиво и как бы логично))

[@dev-workshop]

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

[@RomanDawydkin]

Вместо объекта со значениями true надо использовать Set

[@dev-workshop]

@@RomanDawydkin до определенной версии у вью были проблемы с реактивностью в сетах