Rails 3.2 example application shows how to use subdomains with Devise for authentication.
- 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.
Best of all, there’s a detailed tutorial to show how it’s built.
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 walkthrough tutorial is available on the GitHub wiki:
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.
The example app implements a common use of subdomains, often called “Basecamp-style subdomains in Rails.” Visitors to the main site create a user account which is hosted at a subdomain that matches their user name. Each user has only one subdomain and when they log in, all their activity is confined to their subdomain.
Another common use of subdomains can be called “blog-style subdomains.” This approach is familiar to users of sites such as wordpress.com where each user can create multiple blogs and each is hosted on its own subdomain. For example, a user with the email address “user@example.com@” can own more than one blog, for example, “puppyphotos.wordpress.com” and “kittenphotos.wordpress.com”. The “blog-style subdomains” approach is not implemented in this example application.
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 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-subdomains.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).
You must configure the app for your email account if you want your application to send email messages.
You’ll need to modify two files to include your Gmail username and password:
- config/environments/development.rb
- config/environments/production.rb
config.action_mailer.smtp_settings = {
address: "smtp.gmail.com",
port: 587,
domain: "example.com",
authentication: "plain",
enable_starttls_auto: true,
user_name: ENV["GMAIL_USERNAME"],
password: ENV["GMAIL_PASSWORD"]
}
You can replace ENV["GMAIL_USERNAME"] and ENV["GMAIL_PASSWORD"] with your Gmail username and password. However, committing the file to a public GitHub repository will expose your secret password.
If you’re familiar with setting Unix environment variables, it’s advisable to leave config.action_mailer.smtp_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 GMAIL_USERNAME="myname@gmail.com" export GMAIL_PASSWORD="secret*"
Open a new shell or restart your terminal application to continue.
The example application is set to deliver email in production only. It will raise delivery errors in development but not production.
In development, config.action_mailer.default_url_options is set for a host at localhost:3000 which will enable links in Devise confirmation email messages to work properly. You’ll need to change the config.action_mailer.default_url_options host option from example.com to your own domain for the production environment.
You can change these values as needed in these two files:
- config/environments/development.rb
- config/environments/production.rb
Complete your email configuration by modifying
- config/initializers/devise.rb
and setting the config.mailer_sender option for the return email address for messages that Devise sends from the application.
You can modify the configuration file for Devise if you want to use something other than the defaults:
config/initializers/devise.rb
You’ll want to set up a default user so you can easily log in to test the app. You can modify the file db/seeds.rb for your own name, email and password:
puts 'EMPTY THE MONGODB DATABASE'
Mongoid.master.collections.reject { |c| c.name =~ /^system/}.each(&:drop)
puts 'SETTING UP DEFAULT USER LOGIN'
user = User.create! :name => 'user1', :email => 'user@example.com', :password => 'please', :password_confirmation => 'please'
puts 'New user created: ' << user.name
user2 = User.create! :name => 'user2', :email => 'user2@example.com', :password => 'please', :password_confirmation => 'please'
puts 'New user created: ' << user2.name
Use the defaults or change the values for name, email, and password as you wish.
Prepare the database and add the default user to the database by running the commands:
$ rake db:seed
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.
If you launch the application, it will be running at http://localhost:3000/ or http://0.0.0.0:3000/. However, unless you’ve made some configuration changes to your computer, you won’t be able to resolve an address that uses a subdomain, such as http://foo.localhost:3000/. There are several complex solutions to this problem. You could set up your own domain name server on your localhost and create an A entry to catch all subdomains. You could modify your /etc/hosts file (but it won’t accommodate dynamically created subdomains). You can create a proxy auto-config file and set it up as the proxy in your web browser preferences.There’s a far simpler solution that does not require reconfiguring your computer or web browser preferences. The developer Levi Cook registered a domain, lvh.me (short for: local virtual host me), that resolves to the localhost IP address 127.0.0.1 and supports wildcards (accommodating dynamically created subdomains).
To test the application, visit http://lvh.me:3000/. You should see a list of registered users with links to their profile pages.
Try http://user1.lvh.me:3000/. You should see the profile page for the default user “user1.”
Try http://foo.lvh.me:3000/. You should see the “user not found” error message.
Try http://www.lvh.me:3000/. You should be redirected to the application home page at http://lvh.me:3000/.
To sign in as the default user, (unless you’ve changed it) use
- email: user@example.com
- password: please
You should delete or change the pre-configured logins before you deploy your application.
For your convenience, here are instructions for deploying your app to Heroku. Heroku provides low cost, easily configured Rails application hosting.
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.
The application is set up for RSpec unit tests and Cucumber scenarios and steps. No tests and scenarios are implemented for this version of the example application. Please send the author a message, create an issue, or submit a pull request if you can contribute RSpec or Cucumber tests and scenarios.
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 and steps.
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.
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.
Please create an 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.
Thank you to Brian Cardarella for a helpful blog post on Custom Subdomains in Rails 3.
Daniel Kehoe (http://danielkehoe.com/) 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.
Copyright © 2012 Daniel Kehoe