Skip to content
This repository has been archived by the owner on Mar 8, 2018. It is now read-only.

Configuring Social Sign Up & Sign In

Jump to bottom
Reza Akhavan edited this page Jun 22, 2015 · 7 revisions

The goal of this page is to explain how to setup and configure your Twitter, GitHub, Facebook, Google and Tumblr applications to use the social sign up and sign in with Drywall.

Heads Up

Callback URLs: Each provider allows you to specify a Callback URL. You should only provide the root URL of your application (ex: http://<domain>/) since Drywall is setup to pass the path part of the URL during oauth calls. Be aware that http:// and https:// are considered different, so make sure that the url your making requests from match exactly to your social application settings.

Multiple Environments: You may need to setup separate social apps for each environment you want to test your app in (ex: dev, production, staging). When you're building and testing your app locally, we found that http://localhost:3000/ isn't considered a valid URL... but you can use your local IP address http://127.0.0.1:3000/ instead.

Twitter

  1. Go to https://dev.twitter.com/ and sign in to your account and navigate to My applications.
  2. Click the Create a new application button
  3. Fill out the Name, Description, Website and Callback URL
  4. Got to the Settings tab and find and check the option for Allow this application to be used to Sign in with Twitter

Once your app is created you can get your Consumer key and Consumer secret which you'll need to copy to your /config.js file.

...
exports.oauth = {
  twitter: {
    key: process.env.TWITTER_OAUTH_KEY || 'XXXXXXXXXXXXXXXXXXXXX',
    secret: process.env.TWITTER_OAUTH_SECRET || 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
  },
...
};

GitHub

  1. Go to https://github.com/ and login to your account.
  2. Navigate to Account settings then click on Applications in the left menu.
  3. Click the Register new application button
  4. Fill out the Application name, Homepage URL, Authorization callback URL and Application description

Once your app is created you can get your Client ID and Client Secret which you'll need to copy to your /config.js file.

...
exports.oauth = {
...
  github: {
    key: process.env.GITHUB_OAUTH_KEY || 'XXXXXXXXXXXXXXXXXXXX',
    secret: process.env.GITHUB_OAUTH_SECRET || 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
  }
};

Facebook

  1. Go to https://developers.facebook.com/ and login to your account
  2. Navigate to Manage Apps or Apps
  3. Click the Create New App button
  4. Fill out the App Name, optional App Namespace and App Category
  5. Click on the Edit Settings link
  6. Choose the Website with Facebook Login option

Once your app is created you can get your App ID and App Secret which you'll need to copy to your /config.js file.

...
exports.oauth = {
...
  facebook: {
    key: process.env.FACEBOOK_OAUTH_KEY || 'XXXXXXXXXXXXXXX',
    secret: process.env.FACEBOOK_OAUTH_SECRET || 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
  },
...
};

Google

  1. Go to https://cloud.google.com/console/project and login to your account
  2. Click the Create Project button
  3. Fill out the Project Name, Project ID and click the Create button
  4. Navigate to APIs & auth > Credentials
  5. Click on the Create New Client ID button
  6. Choose the Web application option
  7. For the Authorized JavaScript origins enter http://127.0.0.1:3000/ for local development or when in production your actual domain
  8. For the Authorized redirect URIs you need to enter all the paths where your app will redirect back to. Out of the box you'll need: http://127.0.0.1:3000/signup/google/callback/, http://127.0.0.1:3000/login/google/callback/ and http://127.0.0.1:3000/account/settings/google/callback/.

Once your app is created you can get your Client ID and Client Secret which you'll need to copy to your /config.js file.

...
exports.oauth = {
...
  google: {
    key: process.env.GOOGLE_OAUTH_KEY || 'XXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
    secret: process.env.GOOGLE_OAUTH_SECRET || 'XX_XXXXXXXXXXXXXXXXXXXXX'
  },
...
};

Update 6/21/2015: Google may have updated their control panel. If you're getting failed to fetch user profile or Access Not Configured. The API (Google+ API) is not enabled for your project., you may need to:

Tumblr

  1. Go to http://www.tumblr.com/oauth/apps and login to your account
  2. Click the Register application button
  3. Fill out the Application Name, Application Website fields
  4. For the Default callback URL enter http://127.0.0.1:3000/ for local development or when in production your actual domain
  5. Click on the Register button

Once your app is created you can get your OAuth Consumer Key and Secret Key which you'll need to copy to your /config.js file.

...
exports.oauth = {
...
  tumblr: {
    key: process.env.TUMBLR_OAUTH_KEY || 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
    secret: process.env.TUMBLR_OAUTH_SECRET || 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
  },
...
};

Advanced Technical Details

Drywall uses Passport for it's authentication middleware. Drywall stores the id property from the Passport strategy returned when using the Twitter, GitHub, Facebook, Google or Tumblr strategies. Specifically the id property of the profile returned by Passport.

Jared (the creator of Passport) shared some insight into using the data we get back from the providers.

Profile IDs should all be strings. If there's any strategy that returns them as an integer, it should be patched to cast it to a string.

On _json:

This stores the raw response from the provider's user info endpoint. To facilitate easier integration, Passport normalizes whatever is in that to the Portable Contacts schema, for the "public" profile object. However, often there are many fields that don't map to that schema, which applications are still interested in. In that case, apps are free to dig into the "raw" _json object.

There are some caveats here:

  • Each _json object is going to be different depending on the provider (since there is no common standard).
  • If the provider doesn't serve JSON, there will be no _json object. In this case there will be an _xml or some such that corresponds to the response format.
  • The strategy makes no API guarantees as to the structure of the JSON object. For example, if provider X kills API v1 in favor of API v2, the strategy could suddenly place V2-formatted objects in _json in a patch release.

So basically, use _json with caution, and track any API change notices issued by the provider. For interop, strategies should be patched to increase normalization to PoCo, for any fields that are not currently being mapped.

https://github.com/jedireza/drywall/issues/71#issuecomment-29147826

In Drywall we're just storing the id property of the profile from the Twitter, GitHub, Facebook, Google and Tumblr strategies, nothing more.

Use the Force

I hope this was helpful. If you have questions or think this page should be expanded please contribute by opening an issue or updating this page.

Clone this wiki locally