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

I want to integrate Google's Oauth2 in my symfony 1.4 CRM. I have implemented it successfully, I have implemented it in my own module SfGuardAuth has been extended, and now mysfGuardAuth is being used for siging and signout. Is where I handle Google's Oauth2 with 2 additional actions:

  executeCkeckGoogleAccess (); ExecuteOauth ();  

The problem is that if Google's token is still valid, for checkout, I will redirect each action in each module to checkGoogleAccess in mysfGuardAuth Must have to do module

What do I want to do, it is to check in one place in an inherent manner, where the probe, for correct perms or credentials, before simulating, or sfGuard or executing or executing the requested action.

I want to write code only once.

After some research, sfGuard checks everything

when you If a module requests to take action before performing the operation, then a new sfContext is dispatched. SfContext receives the user who increases sfGuardUser and some methods are executed. is there where the permit, the status of the session, and otherwise is otherwise examined User configured in apps / yourApp / lib

By default Apps / yourApp / lib / myUser which extends to sfGuardUser is the most favorable way of getting: apps / yourApp / lib / yourAppUser Like to create a new user class, which is extending as sfGuardUser, and here you can initialize and / or close Says that with functionality

In this way I have gotten Google's Othe 2 to work in my app.

I hope that this is useful for more people

UPDATE All the truths mentioned above are true, but if you always check something before performing an action If you want to, you should use filters instead of words mentioned earlier. Filters are executed before each action, so you can checkout for the need to access the existing context, and set new features for the user. In my case, I want to check whether the request has been requested that a Google token is required, if true, another filter will check that the user has a valid token, in that case, nothing happens Otherwise, the user is redirected to the module / action which handles the Google token request

Communication user attributes between different filters, actions and requests Is controlled through.