Rails 3.2 example application shows how to use Omniauth with Mongoid.

• OmniAuth manages authentication using a service provider such as Twitter or Facebook.
• MongoDB is used as a datastore with the Mongoid gem for quick development without schemas or migrations.

Best of all, there’s a detailed tutorial to show how it’s built.

• Service Providers: Facebook, Twitter, GitHub, LinkedIn, and many more.
• Gems: Mongoid and OmniAuth plus optional jQuery, Haml, RSpec and Cucumber.

You can build this application in only a few minutes using the Rails Composer tool.

Follow the project on Twitter: @rails_apps. Please tweet some praise if you like what you’ve found.

A complete tutorial is available:

The tutorial documents each step to follow to create the application. Every step is documented concisely, so a complete beginner can create this application without any additional knowledge. However, no explanation is offered for any of the steps, so if you are a beginner, you’re advised to look for an introduction to Rails elsewhere. See a list of recommended resources for Rails.

If you simply wish to modify the application for your own project, you can download the application and set it up as described below, without following the tutorial.

This is a demonstration application that allows you to visit a home page and see a list of users. You can log in using a service provider such as Twitter and view a profile for each user. You can customize this app as you need.

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. For these more complex applications, see other examples and tutorials listed below.

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. See suggestions below for tutorials and examples that combine Devise with OmniAuth.

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, LinkedIn).

This example app shows how to request an email address from the user when he or she first requests access to your application. It is easy to remove this feature if you don’t require it.

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.

Before installing the application, you may wish to contact the service provider you’ll use to obtain any required API keys. The example assumes you will be using Twitter.

Visit https://dev.twitter.com/apps/new to register your application. When you register your application, use the following values:

Visit http://developers.facebook.com/setup to register your application.

Visit https://github.com/account/applications/new to register your application.

Before running this app, you will need:

• The Ruby language (version 1.9.3)
• Rails 3.2
• A working installation of MongoDB (version 1.6.0 or newer)

See the article Installing Rails for advice about updating Rails and your development environment.

If you don’t have MongoDB installed on your computer, you’ll need to install it and set it up to be always running on your computer (run at launch). On Mac OS X, the easiest way to install MongoDB is to install Homebrew and then run the following:

brew install mongodb

Homebrew will provide post-installation instructions to get MongoDB running. The last line of the installation output shows you the MongoDB install location (for example, /usr/local/Cellar/mongodb/1.8.0-x86_64). You’ll find the MongoDB configuration file there. After an installation using Homebrew, the default data directory will be /usr/local/var/mongodb.

You have several options for getting the code.

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!

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/rails3-mongoid-omniauth.git

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

If you want to use the project as a starter app, 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 many additional options.

To build the example application, run the command:

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

Use the -T -O flags to skip Test::Unit files and Active Record files.

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

This creates a new Rails app (with the name “myapp”) on your computer.

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.

Check the Gemfile to see which gems are used by this application.

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.

I recommend using rvm, the Ruby Version Manager, to create a project-specific gemset for the application. See the article Installing Rails.

Mongoid provides access to the MongoDB database from Rails.

You can use the default configuration found in the file config/mongoid.yml.

If you want to see what’s in your MongoDB databases, I recommend using the MongoHub app (for Mac OS X).

This app uses OmniAuth for user management and authentication. OmniAuth is at https://github.com/intridea/omniauth.

You’ll need an OmniAuth initialization file config/initializers/omniauth.rb set up for the service provider you’ll use. For most service providers, you need to register your application and obtain API keys to use their authentication service.

For Twitter:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, ENV['OMNIAUTH_PROVIDER_KEY'], ENV['OMNIAUTH_PROVIDER_SECRET']
end

For Facebook:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :facebook, ENV['OMNIAUTH_PROVIDER_KEY'], ENV['OMNIAUTH_PROVIDER_SECRET']
end

For others, see Module: OmniAuth::Strategies.

You can replace ENV["OMNIAUTH_PROVIDER_KEY"] and ENV["OMNIAUTH_PROVIDER_SECRET"] with your key and secret. However, committing the file to a public GitHub repository will expose your access codes.

If you’re familiar with setting Unix environment variables, it’s advisable to leave the settings unchanged and set your environment variables in the file that is read when starting an interactive shell (the ~/.bashrc file for the bash shell). This will keep the password out of your repository.

Are you using a bash shell? Use echo $SHELL to find out. For a bash shell, edit the ~/.bashrc file and add:

export ENV['OMNIAUTH_PROVIDER_KEY']="your_key"
export ENV['OMNIAUTH_PROVIDER_SECRET']="your_secret"

Open a new shell or restart your terminal application to continue.

When you wish to reset the MongoDB datastore you can run the command:

$ rake db:reseed

Use the db/seeds.rb file to initialize the datastore by creating and saving any model instances you need.

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.

You can check that your app 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 the default user listed on the home page. When you click on the user’s name, you should be required to log in before seeing the user’s profile page.

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.

For your convenience, here are instructions for deploying your app to Heroku. Heroku provides low cost, easily configured Rails application hosting.

No RSpec unit tests or Cucumber scenarios and step definitions are provided.

After installing the application, run rake -T to check that rake tasks for RSpec and Cucumber are available.

Run rake spec to run all RSpec tests.

Run rake cucumber (or more simply, cucumber) to run all Cucumber scenarios.

Please send the author a message, create an issue, or submit a pull request if you can contribute RSpec or Cucumber files.

Problems? Check the issues.

Are you getting an error “OpenSSL certificate verify failed” when you try to generate a new Rails app from an application template? See suggestions to resolve the error Certificate Verify Failed.

The tutorial provides additional documentation.

Ryan Bates offers a Railscast on Simple OmniAuth. You can find documentation for OmniAuth at https://github.com/intridea/omniauth. There is an active OmniAuth mailing list and you can submit OmniAuth issues at GitHub.

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

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

You can also try Rails Hotline, a free telephone hotline for Rails help staffed by volunteers.

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.

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

Copyright © 2012 Daniel Kehoe