Народ, такой вопрос: насколько корректно использовать такого рода валидатор в модели в случае, когда нужно проверять доступ к изменению аттрибута?
['cost', function ($attribute, $params) {
if (array_key_exists($attribute, $this->dirtyAttributes) && !Yii::$app->user->can('manage_product_cost')) {
throw new \yii\web\ForbiddenHttpException('No access to product cost');
}
}],
Отвечая на твой вопрос, подход костыль. Используй разные сценарии например
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Good
Так а зачем усложнять? Его тогда нужно будет вручную загружать из POST
Good
Да ну какие сценарии, они мне тут больше костыльными кажутся
Good
Ну как-как, если у еня все аттрибуты через лоад в модель записываются, то он не сможет в ситуации. когда доступ есть
Good
Мне просто метод через валидатор самым красивым показался
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Так а зачем усложнять? Его тогда нужно будет вручную загружать из POST
нет. Через пост загружаются только безопасные аттрибуты
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Остальное (если есть) устанавливается логикой которую ты определяешь
Good
Ну блин, я ж и говорю. Есть юзеры, которие имеют пермишшн менять это поле, а есть такий, что не могут
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Ну блин, я ж и говорю. Есть юзеры, которие имеют пермишшн менять это поле, а есть такий, что не могут
и? для одних ты одну форму даешь а для других другую
Good
У тех, которые не могут, в форме его не будет, но чисто теоретически можно ж в пост запрос подсунуть, поетому добавил проверку в модели
Good
Ну да, там в форме тоже проверяется доступ, и показываетсяполе ввода
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
У тех, которые не могут, в форме его не будет, но чисто теоретически можно ж в пост запрос подсунуть, поетому добавил проверку в модели
воот... делаешь сценарии. На cost в on определяешь сценарии когда можно менять поле. В остальных случаях даже если в посте будет cost он не изменится.
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
подсунет кто-то без прав в пост значение и пофиг, загружено в модель оно не будет
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
главное без лишних костылей
Good
Ага, а если уже есть несколько сценариев, дублировать каждый?
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
обычный load такого не пропустит
Good
Да и вообще, вроде как не особо рекоммендуют сценарии использовать
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Ага, а если уже есть несколько сценариев, дублировать каждый?
on принимает несколько значений, есть except и т.д.
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
выбери что по душе
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
если совсем сложные различия, используй разные формы
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
вариантов много на все случаи жизни и валидация здесь край, имхо
Good
Я знаю, но просто если есть уже сценарии, то выходит, что нужно будет прописать по два варианта каждого - для юзеров, у которых есть пермишшн, у и у короторых нету
Good
А так просто добавить валидатор на поле. и все
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
cost выделяешь отдельно описываешь один раз и указываешь какие сценарии
Good
Что значит, зачем? А как по другому? Есть, допустим. сценарий на создание нового, и апдейт. И в том, и в другом варианте может быть позвеолено менять кост, а может не быть
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
ну или исключения, в зависимости от логики
Good
Итог - вместо 2 сценариев - 4
Good
КРоме того, нужно тогда где-то этот сценарий в контроллере присваивать, еще один if, и т. д.
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
4 сценария, для каждого валидатора указываешь какие сценарии
Good
Так сложность в том, что зачем? Єто более костільно віглядит и кода больше
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Если ты так уверен что это верно, зачем спрашивать?
Good
А тут просто один валидатор на поле добавить, и все, чем плохо? Идеологически тоже норм. валидатор же проверяет првильность данных, если для этого юзера нельзя вводить ничего в кост, значит форма не валидна
Good
Ну спрашиваю, может есть лутше способ, но это ж явно не сценариями)
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
даже на самый паршивый вариант есть when, но все равно это не место для проверки прав
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
т.к. у тебя аттрибут вообще не должен быть изменен в модели
Good
Не должен. если не пробовать взломать приложение) Поэтому эксепшн выбрасывается
Good
Это же красиво, один валидатор, и все, и в контроллере не нужно ничего менять.
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
В случае со сценариями "левые значения" из "левого поста" не попадут в модель от слова вообще. В твоих случаях ты боишься лишнего сценария и лишенго "if" в контроллере в пользу не очень поддерживаемого решения, которое в т.числе и по производительности дороже
Good
И можно выделить в отдельный класс, и использовать в других подобных случаях
Good
Да там по производительности пофигу, это ж в админке меняется
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
делай как знаешь, чего ты споришь то?)
Good
Дык я думал, может есть более изящное решение, мало ли)
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
ну, я сказал как было бы правильнее сделать
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
что для тебя изящнее для меня загадка)
Good
Кстати, а почему по производительности хуже? ПРоверять пермишшн так или иначе нужно, так какая разница, где - в контроллере, или в валидаторе?)
Good
Ну я понял. спасибо и за это) Все таки, валидатором больше нравится. Вообще. не люблю сценарии, путаница изза них часто
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Стоимость вызова функции
Good
А, ну разве что
Good
Но это соооовсем не критично)
Good
Тут
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Ну я понял. спасибо и за это) Все таки, валидатором больше нравится. Вообще. не люблю сценарии, путаница изза них часто
В плане доступа правильнее использовать сценарии или разные формы, если нужно ориентироваться на разные значения модели то when или динамические формы
Good
Так можно дойти и до того, что обьекты больше ресурсов жрут)
Good
В плане доступа правильнее использовать сценарии или разные формы, если нужно ориентироваться на разные значения модели то when или динамические формы
Я понимаю, но слишком уж много левого кода тогда на такую простую фигню
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
что мешает определить сценарии и на них опираться и во вью и в моделях?
Good
По сути, нужно тогда забацать в модели сценарии, которых там сейчас нету, и в контроллер лезть, проверять. ПРотив простого добавления валидатора - это много
Good
Для такой маленькой задачи - слишком громоздко, как мне кажется
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
в контроллере ты просто определяешь сценарии
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
больше там ничего не нужно
Good
А во вью я через can проверяю
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
а потом проверяешь через can в моделях
Good
Ну ок, а если таких полей будет 5, например? И все могут иметь отдельные пермишшны?
Good
Тогда что, 2 в 5 степени сценариев делать?)
Good
ДЛя всех комбинаций
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
для такого случая нужно думать о других инструментах
Good
Ну а можно просто добавить 5 строчек в метод с валидаторами)
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Например использовать динамические модели
Good
Ну ок, это уже холивар тогда)
☕️ 𝕽𝖔𝖈𝖐𝖊𝖙𝕽𝖆𝖈𝖈𝖔𝖔𝖓
Делай как знаешь, твой проект
Good
По динамических моделях не совсем понимаю, как их тут применить, если есть одна нормлаьная модель уже.
Good
Может тупой вопрос, но все таки: как добавить label в issue на гитхабе? Тупо нет такой опции при создании:
http://prntscr.com/ipi47d
Ivan
Это делают админы проекта
Good
Ааа, понял. Ок)
Yet Another Stats (β)
Карма @offout стала 3
Alexey
Это в каждый контролер в пределах модуля его переделывать?
Нет, достаточно прицепить глобально в конфигурации через as beforeSend