SilverStripe 3.1 OpAuth module. See: http://opauth.org/
1.1 - stable. No known major issues. Report issues using the bug tracker.
The module provides an additional login form which the developer has control over, that allows users to instantly sign in to your website with an identity provided by any Oauth provider. The providers are each handled by using an
OpauthStrategy, many of which are freely available. There are strategies for Facebook, Twitter, Google, and many more.
Based on the identity data from the Oauth provider, the module will find or create a new
Member object based on the provided email address in the identity. This also means a Member can have many Oauth identites linked to a single account; these are saved in to the
If the resultant
Member generated from the provider's response doesn't have an email address, or any other piece of data you require, there is functionality built in to handle this. You can enforce required fields, or any other kind of validation, by setting the
custom_validator property to the class name of the validator you require.
Other than that, the user flow is quite simple. Provided all required data is there, the member is logged in with
Member::login and then redirected to the page they were looking at or the default destination, settable in your config - just like the default
- SilverStripe 3.1 (maybe 3.0, but untested so far)
- At least one Opauth strategy
- Preferably, allow_url_fopen enabled in php.ini. We've written a custom cURL workaround that works with Twitter, Google and Facebook strategies, but it's proprietary.
- For extended cURL support we rely on an opauth fork
- the Opauth core (see below);
OpauthAuthenticator: intended to be comparable with
OpauthLoginForm: which offers different ways you can authenticate;
OpauthRegisterForm: which, if configured, provides an intermediate step so incomplete
OpauthIdentity-authenticating members can fill in extra information as required;
OpauthController: which acts as a negotiator for the communication that strategies undertake;
OpauthIdentity: which acts as a service-agnostic interface with which to save Oauth identities in to the
Memberobject. These are associated with a
Memberupon successful login so that the auth provider's UID and signed response act as a key.
NB: Opauth's maintainers recommend you include strategies as required, rather than bundling them together.
You can find them under the "Available Strategies" heading on the Opauth homepage
Alternatively, you can find them in the bundle package.
Use composer to require your strategies
You define the
member_mapper block in your
_config.yml. Simply provide a hash map of member fields to dot notated paths of the Opauth response array for simple fields, or if you need to perform some parsing to retrieve the value you want, an array of class name and function, like
['OpauthResponseHelper', 'get_first_name']. It takes the auth response array as an argument. See the example config YAML below for more details.
All Opauth-specific configuration variables can be put under
opauth_settings and are passed directly to
You can put these settings in your
_config.yml file. Additionally, as your strategy API details will likely change per domain and thus per environment, you are able to update these using the
Config API. Please see the Opauth config documentation. Here's some examples to help you:
--- Name: silverstripe-opauth After: 'framework/*','cms/*' --- # see the Opauth docs for the config settings - https://github.com/opauth/opauth/wiki/Opauth-configuration#configuration-array OpauthAuthenticator: opauth_settings: #Register your strategies here #Including any extra config Strategy: Facebook: app_id: '' app_secret: '' Google: client_id: '' client_secret: '' Twitter: key: '' secret: '' security_salt: 'correct horse battery staple' security_iteration: 500 security_timeout: '2 minutes' callback_transport: 'session' #Configuration for the Identity-Member mapping OpauthIdentity: member_mapper: Facebook: FirstName: 'info.first_name' Surname: 'info.last_name' Locale: 'raw.locale' Twitter: FirstName: ['OpauthResponseHelper', 'get_first_name'] Surname: ['OpauthResponseHelper', 'get_last_name'] Locale: ['OpauthResponseHelper', 'get_twitter_locale'] Google: FirstName: 'info.first_name' Surname: 'info.last_name' Email: 'info.email' Locale: ['OpauthResponseHelper', 'get_google_locale']
//Register and configure strategies Config::inst()->update('OpauthAuthenticator', 'opauth_settings', array( 'Strategy' => array( 'Facebook' => array( 'app_id' => '', 'app_secret' => '' ), 'Google' => array( 'client_id' => '', 'client_secret' => '' ), 'Twitter' => array( 'key' => '', 'secret' => '' ), ), )); //Identity to member mapping settings per strategy Config::inst()->update('OpauthIdentity', 'member_mapper', array( 'Facebook' => array( 'FirstName' => 'info.first_name', 'Surname' => 'info.last_name', 'Locale' => 'raw.locale', ), 'Twitter' => array( 'FirstName' => array('OpauthResponseHelper', 'get_first_name'), 'Surname' => array('OpauthResponseHelper', 'get_last_name'), 'Locale' => array('OpauthResponseHelper', 'get_twitter_locale'), ), 'Google' => array( 'FirstName' => 'info.first_name', 'Surname' => 'info.last_name', 'Email' => 'info.email', 'Locale' => array('OpauthResponseHelper', 'get_google_locale'), ), ));
NB: As you can see, sometimes the Strategy configuration settings may have inconsistent namings - we can't help with that, sorry!
If you find a bug or have a Really Good Idea™, please raise an issue. Better still, if you can fix the bug, then feel free to send in a pull request with the remidial code that ideally respects the coding conventions used thus far.
- Opauth available under MIT licence by U-Zyn Chua (http://uzyn.com) Copyright © 2012-2013