Rails 4.1
For a Rails 4.1 example application for Devise, see:
A tutorial is available for Devise:
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
- OmniAuth and Rails uses OmniAuth for authentication
- Devise and Rails uses Devise for authentication
Rails 3.2
Rails 3.2 example application shows how to use Devise with Mongoid.
- Devise gives you ready-made authentication and user management.
- MongoDB is used as a datastore with the Mongoid gem for quick development without schemas or migrations.
You really should use the rails-devise newer version.
What Is Implemented — and What Is Not
This is a demonstration application that allows you to visit a home page and see a list of users. With the default user’s email and password (supplied below), you can log in and view details for each user. You can customize this app as you need.
Dependencies
Before generating your application, you will need:
- The Ruby language (version 1.9.3 or 2.0.0)
- The Rails gem (version 3.2.14)
- 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.
Installing MongoDB
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.
On the Debian GNU/Linux operating system, as of March 2013, the latest stable version is MongoDB 2.0.0. With MongoDB 2.0.0, the Mongoid gem must be version 3.0.Ă—. See the Mongoid installation instructions. Change your Gemfile to use an earlier Mongoid version:
gem 'mongoid', '~> 3.0.1'
Getting the Application
You have several options for getting the code.
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/rails3-mongoid-devise.git
You’ll need git on your machine. See Rails and Git.
Generate
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 rails3-mongoid-devise -m https://raw.github.com/RailsApps/rails-composer/master/composer-Rails3_2.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 named rails3-mongoid-devise on your computer.
You’ll see a prompt:
question Install an example application?
1) I want to build my own application
2) membership/subscription/saas
3) rails-prelaunch-signup
4) rails3-bootstrap-devise-cancan
5) rails3-devise-rspec-cucumber
6) rails3-mongoid-devise
7) rails3-mongoid-omniauth
8) rails3-subdomains
Choose rails3-mongoid-devise. The Rails Composer tool may give you other options (other choices 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
question Web server for production?
1) Same as development
2) Thin
3) Unicorn
4) Puma
question Template engine?
1) ERB
2) Haml
3) Slim
extras Set a robots.txt file to ban spiders? (y/n)
extras Use or create a project-specific rvm gemset? (y/n)
extras Create a GitHub repository? (y/n)
Web Servers
Use the default WEBrick server for convenience. If you plan to deploy to Heroku, select “thin” as your production webserver.
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.
Other Choices
Set a robots.txt file to ban spiders if you want to keep your new site out of Google search results.
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.
If you choose to create a GitHub repository, the generator will prompt you for a GitHub username and password.
Troubleshooting
If you get an error “OpenSSL certificate verify failed” or “Gem::RemoteFetcher::FetchError: SSL_connect” see the article OpenSSL errors and Rails.
If you get an error like this:
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
composer Running 'after bundler' callbacks.
The template [...] could not be loaded.
Error: You have already activated ..., but your Gemfile requires ....
Using bundle exec may solve this.
It’s due to conflicting gem versions. See the article Rails Error: “You have already activated (…)”.
Other problems? Check the issues.
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
Install the Required Gems
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.
Configure Mongoid
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).
Configure Email
This example application doesn’t send email messages. However, if you want your application to send email messages (for example, if you plan to install the Devise :confirmable module) you must configure the application for your email account. See the article Send Email with Rails.
Configure Devise
You can modify the configuration file for Devise if you want to use something other than the defaults:
- config/initializers/devise.rb
Configuration File
The application uses the figaro gem to set environment variables. Credentials for your administrator account and email account are set in the config/application.yml file. The .gitignore file prevents the config/application.yml file from being saved in the git repository so your credentials are kept private. See the article Rails Environment Variables for more information.
Modify the file config/application.yml:
# Add account credentials and API keys here. # See http://railsapps.github.io/rails-environment-variables.html # This file should be listed in .gitignore to keep your settings secret! # Each entry sets a local environment variable and overrides ENV variables in the Unix shell. # For example, setting: # GMAIL_USERNAME: Your_Gmail_Username # makes 'Your_Gmail_Username' available as ENV["GMAIL_USERNAME"] # Add application configuration variables here, as shown below. # GMAIL_USERNAME: Your_Username GMAIL_PASSWORD: Your_Password ADMIN_NAME: First User ADMIN_EMAIL: [email protected] ADMIN_PASSWORD: changeme
If you are planning to customize the application to send email using a Gmail account, you can add the user name and password needed for the application to send email. See the article Send Email with Rails.
If you wish, set your name, email address, and password for the first user’s account. If you prefer, you can use the default to sign in to the application and edit the account after deployment. It is always a good idea to change the password after the application is deployed.
All configuration values in the config/application.yml file are available anywhere in the application as environment variables. For example, ENV["GMAIL_USERNAME"] will return the string “Your_Username”.
If you prefer, you can delete the config/application.yml file and set each value as an environment variable in the Unix shell.
Set Up a Database Seed File
The db/seeds.rb file initializes the database with default values. To keep some data private, and consolidate configuration settings in a single location, we use the config/application.yml file to set environment variables and then use the environment variables in the db/seeds.rb file.
puts 'DEFAULT USERS' user = User.create! :name => ENV['ADMIN_NAME'].dup, :email => ENV['ADMIN_EMAIL'].dup, :password => ENV['ADMIN_PASSWORD'].dup, :password_confirmation => ENV['ADMIN_PASSWORD'].dup puts 'user: ' << user.name
You can change the first user’s name, email, and password in this file but it is better to make the changes in the config/application.yml file to keep the credentials private. If you decide to include your private password in the db/seeds.rb file, be sure to add the filename to your .gitignore file so that your password doesn’t become available in your public GitHub repository.
Note that it’s not necessary to personalize the db/seeds.rb file before you deploy your app. You can deploy the app with an example user and then use the application’s “Edit Account” feature to change name, email address, and password after you log in. Use this feature to log in as the first user and change the user name and password to your own.
You may wish to include additional sample users:
user2 = User.create! :name => 'Second User', :email => '[email protected]', :password => 'changeme', :password_confirmation => 'changeme' puts 'user: ' << user2.name
This will add a second user to the database.
Set the Database
Prepare the database and add the default user to the database by running the commands:
$ rake db:seed
Use rake db:reseed if you want to empty and reseed the database. Or you can use rake db:drop and rake db:setup. The equivalent task for Rails with ActiveRecord is rake db:reset which will be available in Mongoid 4.0.
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 your permission. Your secret token should be at least 30 characters long and completely random.
Get a unique secret token:
rake secret
Edit your config/initializers/secret_token.rb file to add the secret token:
Rails3MongoidDevise::Application.config.secret_token = '...some really long, random string...'
Test the App
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 detail page.
To sign in as the default user, (unless you’ve changed it) use
- email: [email protected]
- password: changeme
You should delete or change the pre-configured logins before you deploy your application.
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.
Deploy to Heroku
For your convenience, here are instructions for deploying your app to Heroku. Heroku provides low cost, easily configured Rails application hosting.
Customizing
Devise provides a variety of features for implementing authentication. See the Devise documentation for options.
This example application and tutorial demonstrates Devise and Mongoid working together on Rails 3. Add any models, controllers, and views that you need.
Testing
The example application contains a suite of RSpec unit tests and Cucumber scenarios and step definitions.
After installing the application, run rake -T to check that rake tasks for RSpec and Cucumber are available.
Run rake spec to run RSpec tests.
Run rake cucumber (or more simply, cucumber) to run Cucumber scenarios.
Please send the author a message, create an issue, or submit a pull request if you can contribute improved RSpec or Cucumber files.
Troubleshooting
Problems? Check the issues.
Problems with “Certificate Verify Failed”
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.
Documentation and Support
The tutorial provides additional documentation.
For a Mongoid introduction, Ryan Bates offers a Railscast on Mongoid. You can find documentation for Mongoid at http://mongoid.org/ There is an active Mongoid mailing list and you can submit Mongoid issues at GitHub.
For a Devise introduction, Ryan Bates offers a Railscast on Devise. You can find documentation for Devise at http://github.com/plataformatec/devise. There is an active Devise mailing list and you can submit Devise issues at GitHub.
Issues
Please create an issue on GitHub 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.
You can also try Rails Hotline, a free telephone hotline for Rails help staffed by volunteers.
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.
Contributors
Thank you for improvements to the tutorial by contributors:
MIT License
Copyright © 2012 Daniel Kehoe