Как использовать идентификаторы пользователей составного ключа с Catalyst :: Plugin :: Authentication :: DBI? - PullRequest
Новая
       13

Как использовать идентификаторы пользователей составного ключа с Catalyst :: Plugin :: Authentication :: DBI?

1 голос
/ 05 марта 2010

Какой самый эффективный способ заставить Catalyst::Plugin::Authentication работать, если пользователь uesrid определен доменом (т.е. составной ключ)? Поддерживает ли он эту функциональность? Я специально смотрю на использование Catalyst::Plugin::Authentication::DBI, но я не против разветвления, исправления, воссоздания его, если он не имеет текущей функциональности.

Мне нужно войти на определенное доменное имя с определенным паролем. Кажется, что / all / C:P:A модули зависят от простой комбинации UserID / Password. Другие примеры и советы приветствуются.

Ответы [ 2 ]

7 голосов
/ 06 марта 2010

  1. Catalyst :: Authentication :: Store :: DBIx :: Class поддерживает поиск пользователя по любому виду ключа, который вам нравится, так как вся информация об аутентификации, которую вы предоставляете (за исключением назначенного поля password_), включена в запрос к БД вы можете сделать $c->authenticate({ last_name => "Fred", favorite_color => "Blue" }), если хотите.

  2. Практически все, что вы можете себе представить, возможно, если вы напишите Realm или Store , и нет никаких причин, по которым они должны быть сложными - только классы, которые реализуют один или два метода и наследуют остальные. Какой из них вам придется использовать, зависит от деталей того, что делает ваше приложение - переопределение find_user в Realm было бы проще; написание нового магазина было бы немного сложнее.

0 голосов
/ 08 марта 2010

Реальный ответ: Catalyst::Plugin::Authentication требует от from_session и for_user до обработки только сериализованных ключей : for_user, возвращающих сериализованный ключ, from_session, возвращающих пользователя.Это создает проблему, поскольку C:P:A:DBI в настоящее время не разрешает многоключевых пользователей в реализации своей роли или в реализации from_session и for_user.Как ни странно, он разрешает сложные условия значения ключа в поиске пользователя в find_user.В настоящее время откат является ошибочным предположением, что все пользователи идентифицируются с помощью uid / guid / pkid и т. Д.

Чтобы идентифицировать пользователя с помощью составного ключа, необходимо присоединить условный запросв хранилище или кешируется в for_user сериализованном ключе.И то и другое выполнимо с помощью патча.

Как ни странно, в прошлый раз у меня была такая же путаница Я создал хранилище LDAP 3 года назад .

Я сохранюэтот вопрос открыт до тех пор, пока я не исправлю его, не разберусь с ним, или кто-то не даст полезный соответствующий совет Catalyst::Plugin:: Authentication::Store::DBI.Я переписал этот модуль, и он доступен на http://github.com/EvanCarroll/Catalyst-Authentication-Store-DBI

...