, где sfGuard проверяет perms и учетные данные для реализации Oauth 2

Question

Я хочу интегрировать Oauth2 от Google в свой CRM Symfony-1.4. Я успешно реализовал это, я расширил sfGuardAuth в своем собственном модуле, и теперь mysfGuardAuth используется для сигг и вывесок. Есть там, где я могу обращаться oauth2 Google с 2 дополнительными действиями:

executeCkeckGoogleAccess(); 
executeOauth(); 

Проблема заключается в том, что проверка, если маркер Google по-прежнему является действительным один, я должен перенаправлять в каждом действии everymodule к действию checkGoogleAccess в mysfGuardAuth модуле.

Я хочу проверить это неявным способом в том же месте, где symfony или sfGuard или что-то проверяет правильные perms или учетные данные перед выполнением или без выполнения запрошенного действия.

Я только хочу написать код один раз. Спасибо.

Answer 1

После некоторого исследования это так, как sfGuard проверяет все.

Когда вы делаете запрос к действию модуля перед выполнением действия, рассылается новый sfContext. sfContext получает пользователя, который расширяет sfGuardUser и имеет некоторые методы, которые выполняются. Существует где завивки, состояние сеанса и everithing еще проверяется Пользователь должен быть настроен в apps/yourApp/lib

По умолчанию это apps/yourApp/lib/myUser, который проходит sfGuardUser. Самый простой способ достичь этого - создать новый пользовательский класс, например: apps/yourApp/lib/yourAppUser, который расширяет aswell sfGuardUser и расширяет методы initialize и/или shutdown с необходимой функциональностью.

Таким образом, я достиг, чтобы Oauth2 от Google работал в моем приложении.

Надеюсь, это полезно для большего количества людей.

UPDATE Все описанные выше верно, но если вы хотите проверить, что-то всегда перед выполнением действия необходимо использовать фильтры вместо Whats описано выше. Фильтры выполняются перед каждым действием, поэтому вы можете проверить, что вам нужно иметь доступ к текущему контексту, и настроить новые атрибуты для пользователя. В моем случае я хочу проверить, требуется ли требуемому действию токен google, если true, тогда другой фильтр проверяет, имеет ли пользователь alraedy действительный токен, в этом случае ничего не происходит, иначе пользователь перенаправляется на модуль/действие который обрабатывает запросы токена Google.

Связь между различными фильтрами, действиями и запросами осуществляется через пользовательские атрибуты. пользователь является объектом класса myOwnUser, который расширяет sfGuardSecurityUser, там функция signOut расширяется, чтобы удалить все атрибуты, сохраненные в «myOwnNamespace»