Devise is a popular gem that makes creating user accounts easy. At first, however, it is far from easy. Devise is one of the most complicated gems out there, and it takes some patience and reading to understand all that it's doing under the hood. Once you're familiar with it, it'll save you a lot of time in the long run.
Follow the instructions on the Devise Github page. This is an incredibly important step—most gems you use will have specific instructions that you must follow to get the gem to work properly. It's long, but we highly recommend that you read the instructions. Actually. Then come back to this workflow.
Add gem 'devise' to your Gemfile. Run bundle. Why is more than one gem installed, even though you added only one gem to the Gemfile?
rails generate devise:install. READ THE OUTPUT MESSAGES AND FOLLOW THE INSTRUCTIONS.
Get the views: rails g devise:views. (g is a shortcut for generate.)
Generate a model (note that one must already exist): rails g devise Model, i.e. rails g devise User.
A note about hacking: Like every other things in Rails, Devise might feel like your mom's precious china that you're scared to touch and break. But fear not, this is a natural part of programming. Now that you have the foundations, most of what you'll be doing as you learn is looking stuff up, trying to wrap your head around it on your own, copy-pasting code, and seeing what works and what doesn't. This process is colloquially referred to as "hacking". Not to be confused with malicious hacking (often called "cracking"). Our kind of hacking is a Good Thing.
Devise works with a bunch of different modules that support various functionalities, such as having a "Remember me" button, allowing users to recover passwords, etc. You can look on the README and Wiki (linked to above) for more information. The key thing to remember is when you change functionality, you must change both the model AND the migration. If you've already run the migration, you have to create a new one. Copy-pasting code from the default Devise migration into a new migration will help you.
You can change what's shown to the user by going into app/views/devise and changing the corresponding view. What view should you change? Depends on the behavior—check the documentation.
Unfortunately, there's not rails g devise:controllers. To customize behavior, you often have to extend one of Devise's controllers into your own controller. This sounds tough, but is actually very easy:
Create a new file for your controller in app/controllers. It doesn't matter what you name it, but use something sensible. If you're customizing registration behavior, a good name might be RegistrationsController, and you'd call the file registrations_controller.rb.
Have the controller inherit from the appropriate Devise controller. This is something you'll have to look up online—thankfully, the Devise documentation / Internet at large is good at telling you what the appropriate controller is (you can see the full list here). In the above example, the controller is called Devise::RegistrationsController. So in registrations_controller.rb, you'd type:
# app/controllers/registrations_controller.rb
class RegistrationsController < Devise::RegistrationsController
end
sign_up_params. Why do we put it under the word private? Do we need that?# app/controllers/registrations_controller.rb
class RegistrationsController < Devise::RegistrationsController
private
def sign_up_params
params.require(:user).permit(...)
end
end
config/routes.rb file. You'd replace the line that says devise_for :users with devise_for :users, :controllers => { registrations: 'registrations' }. As you might be able to guess from the syntax, this is where you customize not just controllers, but a lot of other stuff.The How-Tos give step-by-step instructions for basically how to do anything in Devise!
We also learned about a lot of "other stuff" today that has to do with the Rails ecosystem but not with Devise in particular. Here they are, accompanied by some links, so you can read about them on your own time.
Environments allow you to customize behavior depending on how you're working with your application. Rails works with three main environments: development, production, and testing.
You can set custom behavior for each environment in config/environments/.
Gemfile
You can also specify gems that used just for production or development. To see how, check out your Gemfile, you'll see something like group :development do ....
Staging
Staging isn't an official Rails environment, but most companies use one. It's basically a separate server that runs the app in production so that you can check out how your code will behave without actually releasing it. We'll talk more about this later.
Flash messages are one-time status messages that notify the user about successes or failures, i.e. "Successfuly logged in!", or "The user could not be created because of these errors:".
When storing passwords in a database, we should always encrypt them, because if anyone gets access to your database (which will never happen because you're a coding Jedi master, duh), they will then have the user login for every single user who uses your application. That is a Bad Thing.
Indexes help your database find things faster. From Wikipedia:
Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed. Indexes can be created using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records.
Sessions help servers know information about the user, such as whether they're logged in, or certain preferences such as language. Sessions are managed with cookies, which are small bits of code stored on your browser that are sent along with every request. You can view the cookies any site is storing on your brower by opening the development console, going to "Resources", and looking in the "Cookies" tab on the left.
