teddy
Добрый вечер, при добавлении правил в rbac получил вот такую ошибку
PHP Warning 'yii\base\ErrorException' with message 'unserialize() expects parameter 1 to be string, resource given'
после гуглокапания оказалось, что проблема с постгресом, и нашел рецеп поменять поле data c blob на text
ошибка вылезать перестала но и правило не работает
Anonymous
Эта функция ожидает строку а вы передали что то другое ей наверное
teddy
На гите переписка по этому поводу закончилась ничем https://github.com/yiisoft/yii2/issues/10176
Евгений
Добрый вечер, при добавлении правил в rbac получил вот такую ошибку
PHP Warning 'yii\base\ErrorException' with message 'unserialize() expects parameter 1 to be string, resource given'
после гуглокапания оказалось, что проблема с постгресом, и нашел рецеп поменять поле data c blob на text
ошибка вылезать перестала но и правило не работает
У меня как-то такое было, когда я в методе проверки правила юзал di или http client не припомню точно, и когда вот он все это добро сериализировал, все правило целиком возникала подобная аномалия, решил рефакторингом кода, проблема ушла, здесь постгрес не виноват, там также на проекте постгря ...
Евгений
Хотя, сейчас более внимательно прочитав пост еще раз, все-таки, больше похоже на то что действительно что-то не то передается, у меня был illegal offset of bites ...
teddy
У меня как-то такое было, когда я в методе проверки правила юзал di или http client не припомню точно, и когда вот он все это добро сериализировал, все правило целиком возникала подобная аномалия, решил рефакторингом кода, проблема ушла, здесь постгрес не виноват, там также на проекте постгря ...
Я там глубже копнул, оказалось виноват pdo https://bugs.php.net/bug.php?id=53756 . потяно что все можно обойти но хотелось бы понять это я не могу настроить или в принципе не пытаться
Евгений
Я там глубже копнул, оказалось виноват pdo https://bugs.php.net/bug.php?id=53756 . потяно что все можно обойти но хотелось бы понять это я не могу настроить или в принципе не пытаться
Да, там все верно написано, но это не баг pdo, при наличии закрытых или защищенных свойств у объекта юзать бинарный тип у посгри
Евгений
\0 тримится
teddy
\0 тримится
Я вообще сделал все паблик и вернул true. Но правило не сработало. Завтра ещё помучаюсь, а потом буду делать в обход. Думал может здесь есть люди у которых все получилось без бубна
Евгений
Мало информации ... какая иерархия пермишинов, которые используют данное правило? Ты вообще уверен что правильно ее сложил? Если что завтра пиши, будем разбираться ... а то сейчас туго как-то соображается, спать уже пора!)
who are you
свой класс например для отправки сообщений с сайта в телегу где размещать нужно?
who are you
это же не модель
Евгений
Это компонент
Евгений
Врапер над telegram-bot-api!))
who are you
почему это должно быть компонентом ?
who are you
его придется в конфиге подрубать
who are you
а я хотел по типу инклюда
who are you
где надо там и подрубил
Евгений
extends Object, тебе события не нужны, легче будет, и да, подрубил в конфиге и потом дернул где нужно и publish()
Евгений
Мне кажется так идеологически правильно, плюс получаешь конфигурирование объекта как плюшку, ну и например переопределение какой-нить логики, например писать события лога по уровням в разные чат румы
who are you
т.е. любой класс который ты захотел сделать не связанный с сайтом надо делать его компонентом?
who are you
а папку components в common или frontend ?
who are you
Компонент - это базовый класс, который реализует свойства, события и поведение.
Блин ( мне кажется мой класс по отправке сообщения в телеграмм не является событием и поведением
Евгений
Где угодно, главное чтобы тебя было удобно, если используется и со стороны фронта и на беке, то коммон, если где-то в одной части, то в ней соответственно ...
да, такие вот не связанные компоненты повышают реюзабильность кода ... я например инклуды исп только для разбиения конфига на составные части для удобства, чтобы большим не был, например db redis rabbit и тд...
Евгений
Компонент - это базовый класс, который реализует свойства, события и поведение.
Блин ( мне кажется мой класс по отправке сообщения в телеграмм не является событием и поведением
Я же тебе писал, отнаследуйся от yii\base\Object это не помешает ему быть облегченным компонентом ... !)))
Mihail
где надо там и подрубил
Подключение компонента в конфиге еще не значит, что он будет загружен. Только при первом обращении. А это и есть "где надо, там и подрубил", только с центральным конфигом
who are you
yii\base\Object - я так не пробовал еще))
Евгений
Попробуй!)))
who are you
ого как много у него Subclasses
who are you
это чо один из первоначальных классов ? Объект
Anonymous
Привет всем, кто не спит. Столкнулся с неожиданной проблемой. Мне нужно перенести мои пхп классы из папки models в папку forms. Но почему-то когда перемещаю, он автоматом не исправляет пути. А если я это начинаю делать сам, то он попросту не видит app\models\forms. ЧЯДНТ?
Гугол, зараза, молчит.
Anonymous
Сорян, в подпапку forms папки models.
Anonymous
Павел
Я не много не понял после того как я передаю параметры get что с ними делать на сервере или я что то не так сделал ?
Ничего не делать. Пагинатор должен подхватить из строки запроса параметр страницы сам
Borys
Анек за неуловимого Джо уже скидывали?
who are you
вы пользуетесь ? :
yii\behaviors\SluggableBehavior
mr.
Да
mr.
Только там боль с транситерацией из коробки, надо тюнить.
who are you
почему боль, оно же вроде специально и заточено под это дело
mr.
Не само расширение, а правила транслитерации в i18n такие, я как-то занялся вопросом, как по уму переопределить транслитиратор, но это столько действий требовало, ппц, так что проще по месту фиксить всё.
Сергей
Доброе утро! Почитал немного про DDD... интересно, сложно, много дискуссионных моментов :)
Хочу постепенно внедрить в проект, если я правильно понял, сервисный слой. Вижу это так:
1) Оставляем AR-модель.
2) Добавлю в приложении папку services, где будут т. н. сервисы (например, EmployeeService), в нем будут описаны все действия которые можно сделать с AR-моделью.
3) В контролере экшены будут выглядить примерно так:
… Получение сущности и проверка доступа …
try {
$entityService->anythingDo();
} catch (\Exception $e) {
… Обработка исключений …
}
… Вывод …
Покритикуйте. Облегчит ли такой подход разработку с ростом проекта или я не вижу каких-то подводных камней, которые наоборот появятся и усложнят всё?
Сейчас я действия с сущностями, которые используются в нескольких местах, тупо выношу в хелперы и вызываю... И вот от этого хочется избавиться.
Алимжан
Сергей
Насколько я помню, вроде бы вызывается сервисный слой, а не работа с сущностью напрямую
Да, верно, так и задумывал, опечатался :)
mr.
И сущность кидай в сервис)
Алимжан
Лично у меня сейчас в проектах что-то вроде
public function actionRegister()
{
$form = new RegisterForm;
$form->setAttributes(Yii::$app->request->bodyParams);
if ($form->validate()) {
return Yii::$app->userService->register($form);
}
return $form;
}
Алимжан
Это REST
Сергей
И сущность кидай в сервис)
Да, такое и хочу делать,
Идея на вид простая. Берём классический Controller + AR. И делаем Controller + Service + AR.
Controller создаёт AR-томдель, проверяет доступы и отдаёт в сервис, сервис уже выполняет все действия и если есть проблемы - вываливает исключение.
Сергей
Но может что-то упускаю и не всё так просто :)
Dmytro
В самом просто варианте - да, приблизительно так
Dmytro
Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService
Алимжан
Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService
Делал так раньше, не понравилось)
Dmytro
На вкус и цвет
Алимжан
Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService
Зато теперь конструктор не нужно везде объявлять
Сергей
А если через статический метод модели?
Employee::getService() ?
Алимжан
@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)
Алимжан
А если через статический метод модели?
Employee::getService() ?
Кажется будут проблемы с тестированием
Dmytro
А если через статический метод модели?
Employee::getService() ?
Да, во-первых тестирование, во-вторых не в ту сторону зависимости смотрят
Алимжан
@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)
Ясное дело что опять же на вкус и цвет, но я пока не нашел удобного варианта
Алимжан
А как сервис попадает сюда: Yii::$app->userService ?
Тебе в документацию http://www.yiiframework.com/doc-2.0/guide-structure-application-components.html
Сергей
Dmytro
@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)
Смотря какие права :)
Есть понятие "инварианты" - это валидация бизнес-правил вроде "нельзя создать Employee, если его ИНН уже принадлежит другому Employee". Такое в контроллере не проверишь, это идет в сервисный слой.
А есть права доступа к операциям CRUD, реализующиеся через RBAC. Например "создать employee может только пользователь с permission=employee.create". Такое условие как раз хорошо описывается фильтрами в контроллере.
Кроме того, бывают комплексные операции, вроде "импорт сотрудников из файла экспорта 1С", и там permission другой: "employee.import-from-1c". Заметь, что операция импорта - это парсинг + foreach(create), а пермишн - другой. Проверяя это в контроллере, проблем не будет. А если вынести такую проверку в сервис - придётся как-то костылять, чтобы обработать импорт. Уловил? :)
HIT
есть ли готовое решение магазина на yii2, кто что может посоветовать?
Dmytro
Спасибо за развернутый ответ (: Только вот последнее туговато дошло
У тебя есть операция "Импорт пользователей", которая по сути является операцией "Создание пользователя" в цикле. Но право импорта и право создания - разные права
Алимжан
Т.е. все-таки лучше постараться все проверки делать в фильтрах/контроллере? А в сервисном слове можно проверить только для целостности?
Dmytro
Можно иметь право импортировать, но не иметь права создавать и наоборот.
Алимжан
У тебя есть операция "Импорт пользователей", которая по сути является операцией "Создание пользователя" в цикле. Но право импорта и право создания - разные права
Да, уловил)) Просто дольше времени ушло, чем на первые два
Dmytro
Алимжан
Что значит "ВСЕ"?
Сейчас у меня все в длиннющих методах
behavoirs
:
[
'allow' => true,
'actions' => ['update'],
'roles' => ['updatePost'],
'roleParams' => ['postId' => Yii::$app->request->get('id')];
],
А внутри сервиса простая проверка по требованиям бизнес логики, где выкидывается Exception в случае ошибки.
Алимжан
@d_naumenko Просто может быть есть что-то, что избавляет нас от метода
behaviors
на три экрана скролла?
Сергей
@d_naumenko Просто может быть есть что-то, что избавляет нас от метода
behaviors
на три экрана скролла?
В поведениях не понравилось, легко забыть там что-то добавить/убрать. Делаю у себя проверку внутри экшенов:
// Проверка доступа
if (!Yii::$app->user->can('projectParamsEdit', ['project' => $project])) {
throw new ForbiddenHttpException();
}
Так и не придумал ничего умнее))
Anonymous
оберни в функцию помощник
ensureAllow...
Anonymous
Anonymous
не будет ифов лишних по всем экшенам, и в будущем легко отрефакторить