Как же она будет подписана ключём карты если я просто вбиваю все данные на сайте, PAN и прочее и эти данные букинг просто передает и их дальше девочка вводит на терминале. Или вы имеете ввиду как раз в этот момент оно должно было бы быть подписано картой? (И нет, спасибо, пускай другой кто-нибудь попробует :) )
Вопрос автору: правильно ли я понимаю, что если использовать данные вашей карты от эпл пэй из статьи для регистрации на booking .com то тогда данные карты будут квалифицироваться как CP? Ведь они там данные карты по факсу пересылают в отель и отель снимает с вас деньги. Ну по крайней мере по моей последней информации.
А в чем смысл аргументов в аннотации если они статические? И их либо можно передать как дефолтный параметр либо вообще не использовать как параметры т.к. значения заранее известны и поэтому конвертировать их в константы?
Сейчас заметил, что вы используете ModelTransformer. Тогда это все объясняет. Но если переделать на ViewTransformer кода станет меньше и в общем случае процесс будет более наглядный. Т.к. сейчас получается у вас buildView() по факту забрал логику работы DataTransformer'а и полезность ModelTranformer'а стремится к нулю.
Статья в целом хорошая, но есть грубая ошибка с DataTransformer'ами. Они просто напросто у вас не правильно используются. Тот кусок кода, что у вас в buildView() должен быть в методе ->transform().
Метод ->transform() должен выглядеть так:
public function transform($value)
{
if ($value === null) {
return null;
}
return $value->format($this->options['with_seconds'] ? 'H:i:s' : 'H:i');
}
А метод ->reverseTransform() должен выглядеть так:
public function reverseTransform($value)
{
if ($value === null) {
return null;
}
try {
$value = new \DateTime($value);
} catch (\Exception $e) {
throw new TransformationFailedException($e->getMessage());
}
return $value;
}
И еще, т.к. у нас DataTransformer начинает быть зависимым от $options его надо вынести в отдеьный класс, чтобы передавать опции через конструктор.
Будет очень круто, если вы внедрите его у себя в каком-либо проекте. Чем в большем количестве проектов будет использоваться, тем функциональней он будет :)
Несмотря на то, что проект живой (технически) я не представляю, кто в своем уме потянет к себе в проект тот код, который там есть. «Привет из 00-х» грубо говоря. :)
В PHP как таковом — нет, но в архитектуре Symfony2 есть события, например kernel.request. Обычно туда все такие штуки вешают, чтобы для приложеньки это все было «прозрачно».
Тут вижу такой вариант. Из той либы выделить OP, RP. А дальше обновить свои бандлы, например в версии 0.3.x чтобы они были просто враппером для тех библиотек и как раз добавляли этот middleware слой.
В таком случае можно попробовать оживить проект bitbucket.org/PEOFIAMP/phpoidc, который вроде как является полноценной реализацией OIDC. Хотя-бы не в .NET придется ковыряться :)
Судя по вашему комментарию, вы тоже собаку съели на этом. При всем желании, не изобретать велосипед, намерение внеднить что-то масштаба enterprise и на Java/.NET ведет к неумолимому росту сложности проекта в геометрической прогрессии.
Просто представьте себе среднего PHP разработчика, который это увидит? :) В лучшем случае будет разбираться неопределенное кол-во времени, в худшем вообще уйдет из компании )
Перед тем, как я все это начинал делать, я сделал большой ресеч на тему SSO, и компаний, которые его используют. Так вот, Хабр, Яндекс, Google которые я смотрел, почему-то тоже не используют OAuth2 как IdP.
И в какой то мере мне понятна такая политика — для своих же сервисов мы всегда знаем, какие права они хотят получить, и каким права мы можем им дать, в т.ч. данные, которые мы можем им отдавать. OAuth2 тут будет довольно избыточен, т.к. все что нам надо сделать — это аутентифицировать пользователя. Остальное все равно размазано в бизнеслогике приложений.
Далее, если мы будем даже использовать OAuth2 как IdP, то потребность в реализации такого функционала как замоминание SP, с которого пришел пользователь все равно ложится на наши плечи. Да, в OAuth2 есть client_id, но если вы смотрели исодники IdP бандла, то там можно заметить (да и из статьи тоже), что в приложении мы будем оперировать SP не как строкой, которая его идентифицирует, а как инстансом класса этого SP, в который мы можем поместить нашу дополнительную логику, для удобной работы с этим SP из IdP.
Также нам все-равно придется делать всю логику для механизма logout'а. Чтобы юзер был разлогинен на всех сервисах, после того, как нажмет «Выход». Примерно так, как это происходит, когда жмем «Logout» в Google Accounts.
Вернемся к моменту, когда мы выбрали OAuth2 для IdP, и теперь прикинем каким количеством «кастома» нам придется его обернуть/написать, что начинаешь думать, а так ли нужен этот OAuth2? И проще-ли получается?
Все же, мне кажется надо различать когда компании требуется свой SSO, для своих проектов, или когда компании требуется стать провайдером аутентификации, тут безусловно предпочтительнее использовать OAuth2, т.к. 99% придется разным приложениям выдавать разный уровень доступа на чтение к ресурсам пользователя.
Мы у себя сделали _fields парметр, как во всех API. Оно ни в коем случае не заменяет группы, которые мы используем чтобы разделить рендеринг приватной информации от общей.
Нашел еще место для выстрела в ногу: github.com/UnDeleteRU/LikesBundle/blob/master/Helper/LikeHelper.php#L28 ваш хэлпер получился statefull, что само по себе уже не круто, но страшнее другое, в больших приложениях, как показала практика — чень тяжело отследить порой порядок загрузки тех или иных сервисов (их инстанциирование) и вот если ваш LikeHelper вдруг будет инстанциирован до фаервола, то вы там больше никогда не сможете получить объект пользователя в любом из ваших методов. Т.к. в поле класса будет записано null значение, и после инициализации фаервола, далее, после аутентификации пользователя токен будет заполнен, а вот в вашем хэлпере — нет.
Дело в том, что на самом деле, не только не стоило их выделять в LikeHelper (у него и так получилась большая зона ответственности) а воспользоваться существующим компонентом Security, для того, чтобы проверить права доступа к ресурсу. Если ваши строчки заменить на:
$authorizationChecker = $this->get('security.authorization_checker');
if (false === $authorizationChecker->isGranted('LIKE_TOGGLE', $entity) {
throw new AccessDeniedException();
}
А почему у вас используется самопальный EventDispatcher а не нативный, который используется всеми компонентами Symfony2?
Второй вопрос — почему логика ACL возложена на некий LikeHelper а не на стандартный AuthorizationChecker (бывш SecurityContext)?
Ага, ясно. Ваши денежки точно в безопасности тогда (наверное)
Как же она будет подписана ключём карты если я просто вбиваю все данные на сайте, PAN и прочее и эти данные букинг просто передает и их дальше девочка вводит на терминале. Или вы имеете ввиду как раз в этот момент оно должно было бы быть подписано картой? (И нет, спасибо, пускай другой кто-нибудь попробует :) )
Вопрос автору: правильно ли я понимаю, что если использовать данные вашей карты от эпл пэй из статьи для регистрации на booking .com то тогда данные карты будут квалифицироваться как CP? Ведь они там данные карты по факсу пересылают в отель и отель снимает с вас деньги. Ну по крайней мере по моей последней информации.
Метод ->transform() должен выглядеть так:
А метод ->reverseTransform() должен выглядеть так:
И еще, т.к. у нас DataTransformer начинает быть зависимым от $options его надо вынести в отдеьный класс, чтобы передавать опции через конструктор.
Ссылки:
Тут вижу такой вариант. Из той либы выделить OP, RP. А дальше обновить свои бандлы, например в версии 0.3.x чтобы они были просто враппером для тех библиотек и как раз добавляли этот middleware слой.
Просто представьте себе среднего PHP разработчика, который это увидит? :) В лучшем случае будет разбираться неопределенное кол-во времени, в худшем вообще уйдет из компании )
За ссылку на OpenID Connect Session Management 1.0 — draft 23 спасибо. Думаю добавлю это в бандл, полезный функционал.
Так или иначе, из-за того что все на PHP — приходится искать рациональный баланс.
И в какой то мере мне понятна такая политика — для своих же сервисов мы всегда знаем, какие права они хотят получить, и каким права мы можем им дать, в т.ч. данные, которые мы можем им отдавать. OAuth2 тут будет довольно избыточен, т.к. все что нам надо сделать — это аутентифицировать пользователя. Остальное все равно размазано в бизнеслогике приложений.
Далее, если мы будем даже использовать OAuth2 как IdP, то потребность в реализации такого функционала как замоминание SP, с которого пришел пользователь все равно ложится на наши плечи. Да, в OAuth2 есть client_id, но если вы смотрели исодники IdP бандла, то там можно заметить (да и из статьи тоже), что в приложении мы будем оперировать SP не как строкой, которая его идентифицирует, а как инстансом класса этого SP, в который мы можем поместить нашу дополнительную логику, для удобной работы с этим SP из IdP.
Также нам все-равно придется делать всю логику для механизма logout'а. Чтобы юзер был разлогинен на всех сервисах, после того, как нажмет «Выход». Примерно так, как это происходит, когда жмем «Logout» в Google Accounts.
Вернемся к моменту, когда мы выбрали OAuth2 для IdP, и теперь прикинем каким количеством «кастома» нам придется его обернуть/написать, что начинаешь думать, а так ли нужен этот OAuth2? И проще-ли получается?
Все же, мне кажется надо различать когда компании требуется свой SSO, для своих проектов, или когда компании требуется стать провайдером аутентификации, тут безусловно предпочтительнее использовать OAuth2, т.к. 99% придется разным приложениям выдавать разный уровень доступа на чтение к ресурсам пользователя.
Тогда любой, кто бы подключил ваш бандл, могбы накрутить бесконечное количество логики (специфичной для проекта) перед тем, как дать лайкнуть объект, путем имплементации кастомного Voter класса symfony.com/doc/current/cookbook/security/voters_data_permission.html#the-voter-interface у себя в проекте.
Второй вопрос — почему логика ACL возложена на некий LikeHelper а не на стандартный AuthorizationChecker (бывш SecurityContext)?
Кстати да. Включал свой куб спустя месяц, пара светодиодов перестало работать.