та нет ничего

Типа опенсервера под виндой

Тока седня копался у джунши нашей в винде в этом опенсервере... сказал ей ставить линукс. Наказ такой.

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

Ок, пойду гуглить, может что уже для меня собрали.

а что тебе надо то?)

а что тебе надо то?)

https://toster.ru/q/208793

https://toster.ru/q/208793

ммм... тебе не нужен openserver начнем с этого

тебе надо какой-то стэк поднять локально, не более

да и на маке поставить пых как бы дело 15-ти минут

Я просто не хочу каждый раз возиться с настройкой

Под разное окружение и проекты

с настройкой, xdebug и прочими nginx-ами

тогда докер

Я согласен что мне впопенсервер не нужен. Эх, придётся таки докер. ?

тебе понравится

только сразу советую брать dinghy а не docker-for-mac

педалить будет меньше

http://devilbox.org/

Привет, кто-нибудь может обьяснить почему при авторизации не делают просто полномочия через точку, а зачем-то делают роли?

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

точка?

но вообщем, потому что у тебя одна роль можно включать в себя 5 других, например

понятно, я имею в виду в какой момент я пойму что идея писать if ($user->hasPermission('post.view')) окажется неописуемым пиздецом

почему вообще придумали роли, их же точно не ради "пописать на классах" выдумали

hasPermission?

примерно, сразу посмотри, что такое Voter

почему вообще придумали роли, их же точно не ради "пописать на классах" выдумали

потому что RBAC

для чего-то посложнее есть секьюрити воутеры

потому что RBAC

погоди, то есть методику придумали потому что написали стандарт? помоему наоборот как-то должно было быть

и не $user->hasPermission а текущая сессия. Ибо один и тот же пользователь может выступать в разных контекстах

и не $user->hasPermission а текущая сессия. Ибо один и тот же пользователь может выступать в разных контекстах

не понял, пример пожалуйста если можно

погоди, то есть методику придумали потому что написали стандарт? помоему наоборот как-то должно было быть

ну типа роли покрывают большинство юзкейсов и в целом легко обобщаются. А все остальное обобщить сложна

не понял, пример пожалуйста если можно

у меня есть 3 приложения, из одного пользователь может делать чуть больеш чем из другого

тоже хотелось бы узнать что такое "легко обобщить роль" и что такое "сложно обобщить остальное"

или просто множества операцией пересекаются но не полностью

у меня есть 3 приложения, из одного пользователь может делать чуть больеш чем из другого

ага, точно может такое быть... не подумал

тоже хотелось бы узнать что такое "легко обобщить роль" и что такое "сложно обобщить остальное"

"остальное" это правила в духе: - только автор айтема может совершать с ним определенное действие - с айтемом можно завершить действие только если два других чела предварительно заапрувили айтем

их невозможно обобщить.

а RBAC спокойно справляется с примитивными правилами свойственными для круда аля "только админы могут видеть список пользователей"

а как в этом случае поможет роль если на коде смотреть

а вот тот факт что в symfony за каким-то хером сделалии ограничение вида ROLE_%s как формат для роли - это уже да долбоебизм

ну типа разве это полномочие здесь будет? кажется тут уже про статус идет речь

$this->denyAccessUnlessGranted('ROLE_ADMIN');

в контроллере где-нибудь

ну типа разве это полномочие здесь будет? кажется тут уже про статус идет речь

какой статус?

вообще опять же - на данный момент ты никак не ограничен ролями

и если ты хочешь выстраивать иерархии пермишенов с "точкой" (что ни разу не стандарт а какой-то твой конвеншен) - просто напиши воутер который будет это разруливать для тебя

и можно будет писать правила в духе... $this->denyAccessUnlessGranted('post.edit', $post);

симфони секьюрити - калечный компонент ориентированный на базовые кейсы в WEB (не апишки)

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

нет, плохого ничего нет. Просто не из коробки но делается оч легко

вот и задаю вопрос чтобы сразу услышать минусы и принять стандарт не потому что он стандарт а потому что понимаю зачем он

опять же - почему существует это ограничение с ролями - понятия не имею.

мне оно мешает но у меня свои воутеры

и RBAC я юзаю исключительно для самых примитивных вещей

я скорее спрашиваю про работу в целом нежели про симфони, спасибо

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

пытаюсь подготовится к аду

и просто как-то смотрел google.cloud консольку и у них там значит есть роли, а есть пермишены через точку

ну тут сразу скажу - не надо мешать все в одну кучу

и ты типа можешь как две роли присвоить, а можешь отдельно пермишенов натыкать

вот и пытаюсь вникнуть а нахера

так проще)

в их ситуации

пока не пойму- блин сложнее

извини но у них не сказать что задача простая

вот ситуация как ты говорил - юзер может сделать что-то с ресурсом только если два юзера поставили галку

помоему тут речь о с одной стороны - полномочие на изменение, с другой - статус галк

и как бы тут разрулить если роли

или как умнее

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

стандартов тут нет

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

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

то есть уже все чуть-чуть сложнее чем один if в контроллере

понимаю

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

которые требуют разных решений

ситуация которую мы обсуждаем предполагает добавление пермишена на ходу в приложении?

ммм... нет

и соответственно запрет доступа без этого пермишена?

ну то есть хз как ты будешь это делать)

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

конечно как-то скручу все вместе пока пытаюсь понять как делают взрослые люди

хз что тебе будет удобнее в какой момент и какие у тебя ограничения

хорошо, давай пожалуйста вернемся к ролям

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

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

плохо понимаю что ты хочешь

роли могут объединяться в иерархию

примеры можешь в доке той же симфони глянуть

все еще пытаюсь понять почему роль "Юзер" не является пермишеном типа "groups.users"

все еще пытаюсь понять почему роль "Юзер" не является пермишеном типа "groups.users"

потому что роль это роль, а пермишены это пермишены

не нравится мне что масло белое потому что масло белое

роль это кто ты есть сейчас, а пермишены - что тебе можно делать

и масса ситуаций где пермишены определяются исключительно ролью

и достаточно проверить кто ты есть что бы сказать можно тебе это делать или нетт

но и то и то кажется проверяется методом и принцип проверки "есть ли ключ в массиве"

есть еще интересные варианты ролей - при имперсонализации пользователя

я еще с тем не разобрался, в голове нет места для новых имперсонализаций в данный момент