🙅♂️🙆♀️ VUE 3 Ролевая модель, ограничения доступов
HTML-код
- Опубликовано: 8 сен 2024
- Видео о том, как организовать ролевую модель в веб приложении, в частности на фронте. Как настроить доступ по ролям или возможностям. Как прикрутить это красиво и удобно в spa приложения на VUE 3
⚡ Ссылки ⚡
Мой канал в телеграмме - t.me/developer...
Видео про supabase - • 🔍 VUE 3 + бесплатный х...
Github - gitlab.com/Sti...
Посмотрев это видео, понял сколько мне еще учиться xDD
офигенный контент, пожалуйста не забрасывай канал, очень полезные видео, а не просто пересказ доков или объяснения как через v-for список вывести !
Привет! Спасибо за отклик! Я постараюсь, но со временем очень большая напряженка
Самый имбовый способ разделить роли - разные url для разных ролей. Все остальное (в том числе то, о чем говорит автор) для очень простых приложух.
Ну вот здесь я бы поспорил)
Возьмем TeamCity, явно не очень простое приложение или гитлаб
В зависимости от разных доступов на одной странице в интерфейсе, даже в одной менюшке есть разный набор кнопок
@@dev-workshop я тут не прав в том смысле что слово "простые" тут не подходит. Ща попробую сформулировать точнее: если у вас интерфейс админа и юзера отличается целиком а не только лишь парой кнопок и менюшкой, то имеет смысл опереться о url ролевую модель. Это не подойдет лишь в случае если религия не позволяет наблюдать "/userRole/dashboard" в адресной строке. В остальном композиция компонент позволяет прекрасно переиспользовать код и не париться по поводу прав. Я не говорю что та модель которую вы рассмотрели не жизнеспособна, нет, она прекрасно работает но только в ряде случаев.
@@ESTechnonet Дополнив текущую реализацию можно сделать ограничения и по урлам, такми образом будет комбинированная система
для накста очень удобно через pageMeta ограничивать доступы и мидлваркой их отлавливать
Блин классно, в каком то периоде это точно мне понадобится. Спасибо большое.
Пожалуйста :)
Но это не единственное решение и не сильвер булет, перед применением посмотри, возможно другие решение будут более подходящие :)
Ждем новых видео. У тебя очень годный материал!
Спасибо! Надеюсь, весной снова смогу пилить видосы :)
Ты мне открыл глаза. 😳🥹
Но я нифига не понял, но к этому иду. Я начинающий. 😅
Пойду посмотрю все видео.
Надеюсь есть где пишешь все это..
Классный контент, помогает, продолжение этой части с тайпскриптом нужно!
Спасибо! Очень круто!!!!
Рад, что понравилось)
Эх, где это видео было раньше. Столько времени убил чтоб самому допереть до этого)) спасибо. Ещё удобно добавить группы скоупов, особенно если из много и юзеры сами будут рулить доступами
группы скоупов это уже роли)
но мы тоже делали группы, но только чтобы отобразить группой в интерфейсе, а у пользователя связи были только со скоупами)
@@dev-workshop думаю все зависит от сценария. Я пилю щас crud saas и там например у каждого аккаунта рожаются роли и дефолтные пермишены. и если взять скажем роль админа который имеет доступ везде то там без групп получится что надо назначать простыню доступов на пару экранов) а если таких ролей будет несколько то все резко станет сложно) а так я завел группы и если юзер может все с crud сущностью то просто вешаю на нее группу. но в конце концов с бека оно конечно выпрямляется все и фронту прилетают только пермишены.
@@Dikodance интересное решение. Да, я скорее к тому, что с бека прилетал один тип сущностей, по которому определяются доступы. Для единообразия
Крутая тема , давай продолжение , видео понравилось !!!
🔥🔥🔥
Спасибо! полезные знания
Пожалуйста!)
Спасибо!
Пожалуйста:)
Спасибо, жду продолжение видео
А какое продолжение ты ждешь?)
@@dev-workshop вроде было сказано что будет вторая часть с кастомной директорией
@@user-tm5ow3et4l А хочется именно с директивой? Или с компонентом? Или с супер злобной директивой?
@@dev-workshop с директивой лучше. с компонентом все понятно
Спасибо, очень полезное видео
Спасибо!)
Доступно. Полезно. Ждем продолжения.
Спасибо!) Скоро будет еще :)
Спасибо
Пожалуйста :)
Видео полезное, для новичком будет очень здорово, но есть пара нюансов:
1. Глобальный скоуп работает только в рамках шаблона. В скрипте все равно придется доставать хуком или еще как-либо.
2. В данном случае, хоть сама задача авторизации и является глобальной, все таки стоит еще задуматься о том, чтобы сделать хуки импортить от туда хук + енам.
Тем более, если делать директиву или компонент обертку, то это уже не выглядит таким накладным)
1. Полностью согласен, это была распространенная практика со 2 вью, в третьем она почти забыта
2. Такой задачи не стояло, видео и так объемное)
Супер! Спасибо за крутейший контент!!! Очень помогаете) Было бы круто увидеть какой-нибудь мини курс или туториал , так сказать --- разработка небольшого приложения с применение Vue + MongoDB + Express. А еще может GraphQL + Apollo , было тогда вообще бомба! Или заместо Vue , использовать Nuxt 3. Очень помогли бы)
Добрый день, приятно читать, спасибо!) Сейчас как раз изучаю 3 накст. Может быть когда вернусь - появятся видосы по нему :)
@@dev-workshop Было бы прям супер и полезнейше!)) Очень буду ждать, спасибо большое!!!
Полезное видео, спасибо!
Жаль, не так много контента на канале
Привет! Спасибо, в связи с работой сложно выделить время на видосики
Спасибо большое, очень полезное и интересное видео с новым для меня подходом!
Спасибо! 😉
Красава, давно ищю нечто подобное, жаль тайпскрипт не понимаю. Ждём продолжения с компонентом и директивой.
Спасибо! Добавлю в список идей для видео :)
Прикольно. Продолжай бро!)
Спасибо!)
Привет! Очень жаль, что видео перестали выходить довольно продолжительное время😢 Надеюсь, еще появится тут новый, полезный контент!❤
Привет!
Может быть если я найду того, кто будет монтировать видосы, тогда наладится регулярность ))
Если посмотреть пристально то это просто роли ролей. А следовательно не так уж и необходимы. Т.е. ничто не мешает завести ROLE_BOOK_READER и их назначать пользователям.
Так же такой подход рухнет если много разных моделей.
Например на 1 таблицу только для ее просмотра потребуется 3 модели, и по факту для каждой из них придется свою роль завалить. А 3 потому что 1 полная, 2 умеренная, 3 справочник для подстановки.
Ты все правильно говоришь. Однако:
1) Если имеем очень маленькие роли/скоупы/пермишены, их будет много. Чтобы применять их на пользователя нам не очень удобно делать это по одному и мы хотим их объединить в некоторые группы. Группа ролей? Иль роль с несколькими пермишенами/скоупами?
В данном случае роли нужны только для удобства группировки пермишенов/скоупов.
2) Не совсем понял пример с моделями. На справочник для таблиц, в большинстве случаев достаточно иметь один скоуп - loggedIn так, как большой секретности, как правило, в справочниках нет.
Конечно, чем больше логики, чем больше скоупов/пермишеннов/ролей тем сложнее кодовая база.
Однако для веб приложений с ролевой системой, как правило, хватает 3-4 ролей и с ними 20-30 пермишеннов, это достаточно читаемо.
Ну и конечно этот подход не лишен недостатков. Нужно критично относится к информации и анализировать, подойдет ли такой подход вам, или нет :)
Этот подход подходит для меня в большинстве приложений с ролевой системой и я о нем рассказал :)
На бэке на C# в фреймворке такой же подход используется. Только там оно зовется Claims и также используется для раздачи точечных доступов, а подход с только с ролями типа админ , юзер считается уже устаревшим. Так что не утрируй, нормальный пример с раздачей мелких прав. Автору спасибо, за пример
Спасибо за видео, Серег! Предлагаю тему для нового видео: моки для фронта. можно раскрыть разные варианты с плюсами и минусами.
Спасибо за идею!
Огонь!
Рад, что понравилось)
Спасибо за то, что делишся опытом! 16:00 как насчёт provide/inject? И конешно мы все ждём продолжения про дерективу v-scope! И еще было бы интересно, как реализовать авторизацию нескольких аккаунтов (с разными правами) и переключение между ними.
Спасибо!) насчет provide/inject я отношусь к нему сильно хуже, потому что
1) не очень очевидно
2) нужно следить чтобы провайдер существовал в дом дереве, если провайдер лейаут и их несколько - начинается страдание
3) синтаксис и типизация немного страдают
Я видел много боли, которую порождает provide/inject и видил мало проблем, которые он решает.
В видео про аккордион, кстати, используется provide/inject
По поводу разных пользователей - этот видос именно про авторизацию. метод fetchUserOnce как раз загружает информацию и скоупы для конкретного пользователя. ПОсле того, как прикручивается аутентификация, для каждого пользователя будут свои собственные скоупы. В видео я эмулировал это одним моком, но на бою для каждого свои скоупы
Неплохо!
Буду дотягивать до «супер» :)
Буду чертовски благодарен, если прокомментируешь данную логику в контексте приложения с стейт менеджером (Pinia, Vuex).
На самом деле можно оставить всю логику так как она есть вне зависимости есть стейт менеджер или его нет :) Если у вас нет ssr
Если же есть сср, тут и логику поковырять нужно будет и думать как данные с сервера на клиент передать и как раз для этого можно воспользоваться стейт менеджером
Супер круто, посмотрел все видео) всё-таки интересует вопрос.. почему композиция, а не опции? И будут ли видео по композиции. Хотя судя по видео, это уже пройденная тема))
Привет! Я очень рад, что тебе понравилось!
Видео выходят не последовательно а как захочется что-нибудь рассказать :)
Композиция помогла нам всем уйти от миксинов и других болей и принесла новые:)
Когда-нибудь выйдет видео, в котором я расскажу как я пишу приложения без стора, разделив все на домены и сервисы. Но чуть позже :)
P.S. мне опции нравятся больше, чем композиция и новая система реактивности, однако старые подходы имели проблемы с разделением ui и логики.
Динамические группы/роли/скоупы то еще зло на деле, хоть и звучит красиво и как бы логично))
Я согласен, но иногда от этого никуда не уйти)
Здравствуйте, можете сделать пожалуйста видео про авторизацию.
Здравствуйте, может быть ближе к лету, если найду редактора для видео
А нужна ли вообще директива для доступов? По моему получится велосипед в виде кастомного v-if
Скорее философский вопрос) Да, это будет кастомный v-if. Да, можно использовать просто v-if. Но идея директивы для доступов разделить условное отображение связанное с бизнес логикой и условное отображение связанное с ролевыми доступами
Плюс по такой директиве легко прочитать доступы прям в шаблоне, тогда как условия v-if часто заворачиваются в компьютед свойства, для которых нужно лезть в код
сделаешь подробнее уроки с vue laravel по этой теме?
Привет! Я не особо умею в PHP :( по этому скорее нет. Плюч видео сейчас временно не выходят
Спасибо за видео, было полезно. Есть вопросик такой...
А как решать проблему доступа к определённым объектам? Допустим, мы даём удалять книгу только тому, кто её создал. При этом всем пользователям видны все книги. Пытался продумать это в рамках этих скоупов, но что-то "не выходит каменный цветок".
Рад, что видео понравилось! Такое ограничение точно должно быть известно бекенду, соответсвенно есть несколько вариантов: проставить флаг на беке, зашить поле scopes для каждого объекта на беке и докрутить логику на фронте, зашить эту логику на фронте, путём сравнения Id текущего пользователя и автора книги. У каждого способа есть свои плюсы и недостатки, нужно смотреть на конкретный проект
@@dev-workshop ещё вопрос. Сергей, почему scope, а не permission? Просто более короткая запись?
@@Markeldo Скорее вкусовщина) На моей первой работе были скоупы и я к ним привык)