Rails and OmniAuth

Rails 5.0 example application that integrates Rails and OmniAuth. OmniAuth is a gem that provides authentication using third-party credentials such as Facebook, Twitter, or GitHub accounts.

You can build this application in only a few minutes using the Rails Composer tool, choosing either a Bootstrap or Foundation front-end framework, as well as many other options, such as Haml or Slim.

Our Rails and OmniAuth tutorial explains the application in-depth so there is no mystery code.

From the RailsApps Project

The RailsApps open source project offers starter applications and tutorials for Rails developers. Generate the applications with the Rails Composer tool.

All the code is explained in the Capstone Rails Tutorials. You can purchase the Capstone Rails Tutorials to support the project.

If You Are New to Rails

If you’re new to Rails, see What is Ruby on Rails?, the book Learn Ruby on Rails, and recommendations for a Rails tutorial.

What Is Implemented — and What Is Not

The example application can be used as the basis for a website that provides a login using a Twitter account. You can easily substitute any other provider supported by OmniAuth. With knowledge of Rails, the website can be adapted and customized to your needs. Features include:

• Home page
• Navigation bar
• Login
• Logout
• Show user profile
• List of users

The list of users is visible to anyone. Use authentication to restrict it to the user who was created first, or implement authorization to restrict it to an administrator. See the rails-devise-pundit example application if you wish to add authorization.

Single Provider or Multiple Providers?

This application is designed for sign-in with a single provider. For example, you may be creating an application just for Twitter users. Alternatively, it’s possible to create an application that lets a user log in using multiple providers. This example application doesn’t show the more complex use of multiple providers.

When to use Devise?

Devise provides authentication using username (or email address) and password. If you don’t need the option of using a username/password, that is, if you wish to have all your users sign in using a service provider’s account (such as Twitter or Facebook), there’s no need to use Devise. Devise can be used in conjunction with the OmniAuth gem when you need to offer users the option of signing up for access to a website using an email address. For example, combine Devise with OmniAuth to accommodate users who want to log in with various service providers (Twitter, Facebook, etc.) as well as users who don’t have external accounts and want to sign up with just an email address.

The Email Problem

You don’t need to ask a visitor for an email address when you build an application that allows a user to log in using a service provider such as Twitter or Facebook. You may consider that an advantage: if a user is logged in with Twitter or Facebook, they don’t need to enter an email address and password to access your application. However, the lack of an email address may be a business drawback, if you want the opportunity to stay in contact with the user by email. Some service providers provide the user’s email address to your application (Facebook). Some service providers only provide the email address at the user’s option (GitHub supplies it if the user has provided a public email address). And other service providers do not provide the email address at all (Twitter, Meetup, LinkedIn). Our Rails and OmniAuth tutorial shows how to customize the application to ask for an email address when the user signs in for the first time.

Database

The application requires a database. The example application uses SQLite with Rails ActiveRecord. You can easily substitute PostgreSQL, MySQL, or other databases.

Front-end Framework

The example application (here in the GitHub repository) includes simple CSS for a navigation bar and flash messages. The rails_layout gem is included so you can add the Bootstrap or Foundation front-end frameworks.

Similar Examples and Tutorials

This is one in a series of Rails example apps and tutorials from the RailsApps Project. See a list of additional Rails examples, tutorials, and starter apps. Related example applications may be useful:

• Learn Rails companion to the book Learn Ruby on Rails
• Foundation and Rails shows how to integrate Foundation
• Bootstrap and Rails shows to integrate Bootstrap
• Devise and Rails shows to use Devise for authentication
• Devise and Pundit and Rails uses Pundit for authorization

Accounts You Will Need

Heroku

We provide instructions to deploy the application to Heroku which provides Rails application hosting. It costs nothing to set up a Heroku account and deploy as many applications as you want. To deploy an app to Heroku, you must have a Heroku account. Visit Heroku to set up an account.

Obtaining API Keys

Before installing the application, register with a service provider to obtain the required API keys. The example assumes you will be using Twitter.

Twitter

Visit the Twitter Create an application page to register your application. You can use the following values when you register your application:

Facebook

Visit the Facebook Developer Site to register your application.

GitHub

Visit GitHub’s Register a new OAuth application page to register your application.

Others

See the OmniAuth List of Strategies page.

Dependencies

Before generating your application, you will need:

• The Ruby language – version 2.3.1
• The Rails gem – version 5.0

See the article Installing Rails for instructions about setting up Rails and your development environment.

Getting the Application

Local

You have several options for getting the code on your own machine. You can fork, clone, or generate.

Fork

If you’d like to add features (or bug fixes) to improve the example application, you can fork the GitHub repo and make pull requests. Your code contributions are welcome!

Clone

If you want to copy and customize the app with changes that are only useful for your own project, you can clone the GitHub repo. You’ll need to search-and-replace the project name throughout the application. You probably should generate the app instead (see below). To clone:

$ git clone git://github.com/RailsApps/rails-omniauth.git

You’ll need git on your machine. See Rails and Git.

Generate

If you want to use the project as a starter application, use the Rails Composer tool to generate a new version of the example app. You’ll be able to give it your own project name when you generate the app. Generating the application gives you additional options.

To build the example application, Rails 5.0 must be installed in your development environment. Run the command:

$ rails new rails-omniauth -m https://raw.github.com/RailsApps/rails-composer/master/composer.rb

The $ character indicates a shell prompt; don’t include it when you run the command.

This creates a new Rails app named rails-omniauth on your computer. You can use a different name if you wish.

You’ll see a prompt:

option  Build a starter application?
    1)  Build a RailsApps example application
    2)  Contributed applications
    3)  Custom application

Enter “1” to select Build a RailsApps example application. You’ll see a prompt:

option  Choose a starter application.
    1)  learn-rails
    2)  rails-bootstrap
    3)  rails-foundation
    4)  rails-mailinglist-activejob
    5)  rails-omniauth
    6)  rails-devise
    7)  rails-devise-roles
    8)  rails-devise-pundit
    9)  rails-signup-download
   10)  rails-stripe-checkout

Choose rails-omniauth. The Rails Composer tool may give you other options (other applications may have been added since these notes were written).

The application generator template will ask you for additional preferences:

 question  Web server for development?
       1)  WEBrick (default)
       2)  Thin
       3)  Unicorn
       4)  Puma
       5)  Phusion Passenger (Apache/Nginx)
       6)  Phusion Passenger (Standalone)
 question  Web server for production?
       1)  Same as development
       2)  Thin
       3)  Unicorn
       4)  Puma
       5)  Phusion Passenger (Apache/Nginx)
       6)  Phusion Passenger (Standalone)
 question  Database used in development?
       1)  SQLite
       2)  PostgreSQL
       3)  MySQL
       4)  MongoDB
 question  Template engine?
       1)  ERB
       2)  Haml
       3)  Slim
 question  Test framework?
       1)  None
       2)  RSpec with Capybara
 question  Front-end framework?
       1)  None
       2)  Twitter Bootstrap 3.3
       3)  Twitter Bootstrap 2.3
       4)  Zurb Foundation 5.5
       5)  Zurb Foundation 4.0
       6)  Simple CSS
 question  OmniAuth provider?
       1)  Facebook
       2)  Twitter
       3)  GitHub
       4)  LinkedIn
       5)  Google-Oauth-2
       6)  Tumblr
 question  Use a form builder gem?
       1)  None
       2)  SimpleForm
   extras  Set a robots.txt file to ban spiders? (y/n)
   extras  Create a GitHub repository? (y/n)
   extras  Use or create a project-specific rvm gemset? (y/n)

Web Servers

If you plan to deploy to Heroku, select Unicorn as your production webserver. Unicorn is recommended by Heroku.

Database

Use SQLite for development on Mac or Linux, unless you already have PostgreSQL installed locally. Use PostgreSQL if you plan to deploy to Heroku. You can easily change the database later if you select SQLite to start.

Template Engine

The example application uses the default “ERB” Rails template engine. Optionally, you can use another template engine, such as Haml or Slim. See instructions for Haml and Rails.

Testing

If you are a beginner, select “None.”

Front-end Framework

The example in the GitHub repository was built using “Simple CSS.” Use Zurb Foundation or Bootstrap if you prefer.

OmniAuth Provider

Choose the service provider you will use. The example application uses Twitter.

Other Choices

Set a robots.txt file to ban spiders if you want to keep your new site out of Google search results.

If you choose to create a GitHub repository, the generator will prompt you for a GitHub username and password.

It is a good idea to use rvm, the Ruby Version Manager, and create a project-specific rvm gemset (not available on Windows). See Installing Rails.

Troubleshooting

If you get an error “OpenSSL certificate verify failed” or “Gem::RemoteFetcher::FetchError: SSL_connect” see the article OpenSSL errors and Rails.

Edit the README

If you’re storing the app in a GitHub repository, please edit the README files to add a description of the app and your contact info. If you don’t change the README, people will think I am the author of your version of the application.

Getting Started

See the article Installing Rails to make sure your development environment is prepared properly.

Use RVM

I recommend using rvm, the Ruby Version Manager, to create a project-specific gemset for the application. If you generate the application with the Rails Composer tool, you can create a project-specific gemset.

Gems

Here are the gems used by the application:

• omniauth
• omniauth-twitter

These gems make development easier:

• better_errors – helps when things go wrong
• rails_layout – generates files for an application layout

Your choice of front-end framework:

• bootstrap-sass – Bootstrap for CSS and JavaScript
• foundation-rails – Zurb Foundation for CSS and JavaScript

Install the Required Gems

If you used the Rails Composer tool to generate the example app, the application template script has already run the bundle install command.

If not, you should run the bundle install command to install the required gems on your computer:

$ bundle install

You can check which gems are installed on your computer with:

$ gem list

Keep in mind that you have installed these gems locally. When you deploy the app to another server, the same gems (and versions) must be available.

Front-end Framework

If you generate the application using the Rails Composer tool, you have the option to install either Bootstrap or Foundation. The folder app/views/devise/ will contain attractive view files that override the views provided in the Devise gem.

The example application in the repository is set up with Bootstrap. If you wish to replace Bootstrap with Foundation, first set up the Gemfile:

Remove:

gem 'bootstrap-sass'

Add:

gem 'foundation-rails'

Use Bundler to install the gem:

$ bundle install

To create layout files for use with Zurb Foundation 5.5:

$ rails generate layout:install foundation5

Configuration File

To consolidate configuration settings in a single location, we store credentials in the config/secrets.yml file. To keep your credentials private, use Unix environment variables to set your credentials. See the article Rails Environment Variables for more information.

Add your credentials to the file config/secrets.yml:

# Make sure the secrets in this file are kept private
# if you're sharing your code publicly.

development:
  omniauth_provider_key: <%= ENV["OMNIAUTH_PROVIDER_KEY"] %>
  omniauth_provider_secret: <%= ENV["OMNIAUTH_PROVIDER_SECRET"] %>
  secret_key_base: very_long_random_string

test:
  secret_key_base: very_long_random_string

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  omniauth_provider_key: <%= ENV["OMNIAUTH_PROVIDER_KEY"] %>
  omniauth_provider_secret: <%= ENV["OMNIAUTH_PROVIDER_SECRET"] %>
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

All configuration values in the config/secrets.yml file are available anywhere in the application as variables. For example, Rails.application.secrets.omniauth_provider_key will return the string set in the Unix environment variable OMNIAUTH_PROVIDER_KEY.

Set the omniauth_provider_key and omniauth_provider_secret with the credentials you obtained when you set up your application with Twitter or another provider.

If you don’t want to use Unix environment variables, you can set each value directly in the config/secrets.yml file. The file must be in your git repository when you deploy to Heroku. However, you shouldn’t save the file to a public GitHub repository where other people can see your credentials.

Database Seed File

The db/seeds.rb file initializes the database with default values. This example application doesn’t require seeding the database.

Set the Database

If you’ve used the Rails Composer tool to generate the application, the database is already set up with rake db:migrate and rake db:seed.

If you’ve cloned the repo, prepare the database by running the commands:

$ rake db:migrate
$ rake db:seed

Use rake db:reset if you want to empty the database.

Set the database for running tests:

$ rake db:test:prepare

If you’re not using rvm, the Ruby Version Manager, you should preface each rake command with bundle exec. You don’t need to use bundle exec if you are using rvm version 1.11.0 or newer.

Change your Application’s Secret Token

If you’ve used the Rails Composer tool to generate the application, the application’s secret token will be unique, just as with any Rails application generated with the rails new command.

However, if you’ve cloned the application directly from GitHub, it is crucial that you change the application’s secret token before deploying your application in production mode. Otherwise, people could change their session information, and potentially access your site without permission. Your secret token should be at least 30 characters long and completely random.

Get a unique secret token:

rake secret

Edit the config/secrets.yml file to change the secret token.

Test the App

You can check that your application runs properly by entering the command:

$ rails server

To see your application in action, open a browser window and navigate to http://localhost:3000/.

You should see a home page with a navigation bar.

You should be able to click the navigation link for “Login.”

If you’ve already registered your application with Twitter (or another provider) and set your credentials in the config/secrets.yml file, the application will redirect to the provider’s authorization page. After authorizing access, you will be redirected back to the example application.

Stop the server with Control-C. If you test the app by starting the web server and then leave the server running while you install new gems, you’ll have to restart the server to see any changes. The same is true for changes to configuration files in the config folder. This can be confusing to new Rails developers because you can change files in the app folders without restarting the server. Stop the server each time after testing and you will avoid this issue.

RSpec Test Suite

The application contains a suite of RSpec feature tests. To run:

$ rspec

Deploy to Heroku

Heroku provides low cost, easily configured Rails application hosting.

You can deploy from the command line.

$ git push origin master

If you’ve set configuration values in the config/secrets.yml file, you’ll need to set them as Heroku environment variables. You can set Heroku environment variables directly with heroku config:add. For example:

$ heroku config:add OMNIAUTH_PROVIDER_KEY='Your_Provider_Key' OMNIAUTH_PROVIDER_SECRET='Your_Provider_Secret'

See the Tutorial for Rails on Heroku for details.

Troubleshooting

Problems? Check the issues.

Issues

Please create a GitHub issue if you identify any problems or have suggestions for improvements.

Where to Get Help

Your best source for help with problems is Stack Overflow. Your issue may have been encountered and addressed by others.

Use the tag “railsapps” on Stack Overflow for extra attention.

Contributing

If you make improvements to this application, please share with others.

Send the author a message, create an issue, or fork the project and submit a pull request.

If you add functionality to this application, create an alternative implementation, or build an application that is similar, please contact me and I’ll add a note to the README so that others can find your work.

Credits

Daniel Kehoe implemented the application and wrote the tutorial.

Is the app useful to you? Follow the project on Twitter: @rails_apps
and tweet some praise. I’d love to know you were helped out by what I’ve put together.

MIT License

MIT License

Copyright ©2014-16 Daniel Kehoe

Useful Links