where sfGuard checks out perms and credentials in order to implement Google's Oauth 2

Question

I want to integrate Google's Oauth2 in my symfony-1.4 CRM. I have successfully implemented this, I have extended sfGuardAuth in my own module, and now mysfGuardAuth is being used for siging and signout. Is there where I handle Google's Oauth2 with 2 extra actions:

executeCkeckGoogleAccess();
executeOauth();

The problem is to checkout if Google's token is still a valid one, I have to redirect in each action of everymodule to the action checkGoogleAccess in mysfGuardAuth module.

What I want is to check this in an implicit way in the same place where symfony, or sfGuard or whatever checks for the right perms or credentials before executing or not executing the requested action.

I only want to write the code once. Thank you.

Answer 1

After some research this is how sfGuard checks everything.

When you make a request to a module action, before the action is executed, a new sfContext is dispached. The sfContext gets the user that extends sfGuardUser and has some methods that are executed. There is where perms, session status and everithing else is checked The user must be configured in apps/yourApp/lib

By default is apps/yourApp/lib/myUser which extends sfGuardUser. The most apropiate way to achieve this is to create a new user class like: apps/yourApp/lib/yourAppUser which extends aswell sfGuardUser, and there extend the methods initialize and/or shutdown with the functionality you want.

By this way I have achieved to get Google's Oauth2 working in my app.

I hope this is usefull for more people.

UPDATE All described above is true, but if you want to check something always before an action execution you must use filters instead of whats described before. Filters are executed before each action, so there you can checkout whatever you need having access to the current context, and set up new attributes for the user. In my case I wanna check if the requested action needs a google token, if true, then Another filter will check if the user has alraedy a valid token, in that case, nothing happens, otherwise, the user is redirected to the module/action which handles google token requests.

Comunication between diferent filters, actions and requests are handled via user attributes. the user is an object of the clas myOwnUser which extends sfGuardSecurityUser, there the function signOut is extended in order to delete all attributes saved in "myOwnNamespace"