Аутентифікація в Perl web-фреймворку Catalyst (catalyst perl aaa auth)
Ключові слова: catalyst

, perl , aaa , auth , ( знайти схожі документи )
From: Alex Povolotsky < [email protected]. > Newsgroups: email Date: Mon, 16 Mar 2009 Повідомлення 17:02:14 +0000 (UTC) Subject: Аутентифік Perl web-фреймворку Catalyst Практично будь-який веб-додаток так чи інакше потребує реалізації трьох А - Аутентифікації, Авторизации і Аграніченія доступу . (В оригіналі - Authentication, Authorization, Access control) У зв'язку з великим попитом на цього суспільно-корисної справи, автори Catalyst перенесли його з плугинов в власне систему і зробили модульним. Одне тільки забули - написати до цього виразну документацію. Намагаюся заповнити цю прогалину в міру сил. Поки - в частині першого А. Процес Аутентифікації полягає в тому, щоб переконатися, що клієнт, який представився, як root, дійсно таким є. В принципі, після цього корисно зберегти інформацію про візит в сесії, і, якщо є така можливість, згадати про нього що-небудь корисне - дату останнього логіна, ім'я-прізвище, список боргів ... $ c-> user_exists повертає 1, якщо у нас в сесії позначено, що користувач успішно залогінився, $ c-> user повертає покажчик на об'єкт (швидше за все, типу C :: A :: User :: Hash, спадкоємець Class :: Accessor :: Fast), з якого можна витягти все, що ми знаємо про юзера. Для зберігання інформації служать модулі Catalyst :: Authentication :: Store :: *, представлені готовими модулями C :: A :: S :: Null, C :: A :: S :: Minimal і C :: A :: S :: DBIx :: Class. Найважливіша функція C :: A :: S :: * - find_user ($ authinfo, $ c), де $ authinfo - це хеш з даними, що використовуються для пошуку, а $ c в рекомендацій не потребує. Null взагалі не утруднюється зберіганням інформації - йому передають хеш з даними, він і повертає їх зі словами "Ось, я все про нього знаю". Null дуже зручний для зовнішніх механізмів аутентифікації. Minimal зберігає у власній конфігурації всю інформацію. DBIx :: Class, як нескладно здогадатися, зберігає дані в базі. В налаштуваннях DBIx :: Class вказується, в якому класі зберігаються дані і в якому полі - ідентифікатор користувача. Ще DBIx :: Class вміє автоматично додавати успішно авторизованих (зовнішньої авторизацією) користувачів в базу, але це я як-небудь іншим разом розповім. Для перевірки валідності користувача служать модулі Catalyst :: Authentication :: Credential :: * (штатно реалізований модуль C :: A :: C :: Password). Головна деталь цього модуля - функція authenticate, параметрами якої є улюблений $ c, якого і так все знають, $ realm, про який мова піде нижче, і $ authinfo, що представляє собою хеш різних корисних даних, типу кігтів, за якими ще стародавні римляни визначали лева. Власне, ця функція шукає інформацію про користувача і звіряє її з $ authinfo, повертаючи або undef, що означає, що перед нами - пройдисвіт, чи правильно благословенний хеш з інформацією про користувача. Зрозуміло, для цього використовується get_user. C :: A :: Password підтримує кілька видів паролів, включаючи таку екзотику, як none. Наприклад, якщо ми використовуємо штатну аутентифікацію апача, то в стандартну схему ми вписуємося дуже легко і красиво - Password з паролем типу none, і C :: A :: S :: Null. / Login ми захищаємо http-авторизацією з апачевского конфіга, а все інше - дивимося через сесію. Для об'єднання Credential і Store служить поняття Realm (C :: A :: Realm). Власне, завдання Realm'а - це об'єднати сім кутів під одним дахом зберігання і спосіб перевірки користувача під якимсь ім'ям, а також додати в $ c функцію authentcate ($ userinfo, $ realm). Так, ще в $ c є функція user_in_realm ($ realm), яка перевіряє не тільки факт залогіненним користувача, але і приналежність його до області. Таким чином, ми отримуємо досить гнучку аутентифікацію і якесь примітивне поділ привілеїв. Конфігурація всього цього в project.yml описана кривее всього. Я дозволю дати найпростіший приклад з поясненнями. Authentication: default_realm: users realms: users: credential: class: Password password_field: password password_type: hashed password_hash_type: md5 store: class: DBIx :: Class user_class: Main :: Users id_field: login У принципі, в світлі вищевикладеного все зрозуміло. $ C-> authenticate ({login => $ form-> param ( 'login'), password => $ form-> param ( 'password')}) робить там, всередині, $ user = $ c-> model ( 'Main :: Users') -> find ({login => $ form-> param ( 'login')}), потім перевіряє md5_hex ($ form-> param ( 'password')) на збіг з $ user-> password, при успіху всі дані з $ user закручуються в C :: A :: User :: Hash і повертаються назад, при неуспіху повертається null.

Обговорення [ RSS ]

• 1 , анонім (-), 17:24, 19/03/2009 [ відповісти ]

+

/ - Я правильно зрозумів, що це через base аутентифікацію, а не через сесійний куку робиться?

• 2 , Alex Povolotsky (?), 14:53, 20/03/2009 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > Я правильно зрозумів, що це через base аутентифікацію, а не через сесійний
> Куку робиться?

Що це"? Те, що з конфіг? Через сесійний куку. base згадано окремо.

Додати коментар

Спонсори:

Хостинг: