Summer’s over — what’s your move? Join Pro for 50% off using code [MAKEITHAPPEN](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=MAKEITHAPPEN)


Build a system to let users sign up, log in, and log out of your app.

Authentication

Well done! 

1. When you visit the URL `/login`, the browser makes a GET request for the URL. This request hits the Sessions controller's `new` action, which returns a view displaying the login page.
2. In the login form, we use `form_for(:session, url: login_path) do |f|`. This refers to the name of the resource and corresponding URL. In the signup form, we used `form_for(@user) do |f|` since we had a User model. For the login form, we don't have a Session model, so we refer to the parameters above. 


Login II

Using the <a href="https://www.codecademy.com/articles/request-response-cycle-forms" target="_blank">request/response cycle</a> as a guide, here's how authentication fits in:

**Turn one:**
1. When a user visits the signup page, the browser makes an HTTP GET request for the URL `/signup`. 
2. The Rails router maps the URL `/signup` to the Users controller's `new` action. The `new` action handles the request and passes it on to the view. 
3. The view displays the signup form.

**Turn two:**
1. When the user fills in and submits the form, the browser sends the data via an HTTP POST request to the app.
2. The router maps the request to the Users controller's `create` action.
3. The `create` action saves the data to the database and redirects to the albums page. The action also creates a new _session_.

What is a session? A session is a connection between the user's computer and the server running the Rails app. A session starts when a user logs in, and ends when the user logs out.

User Model

How do these methods work?

1. The `current_user` method determines whether a user is logged in or logged out. It does this by checking whether there's a user in the database with a given session id. If there is, this means the user is logged in and `@current_user` will store that user; otherwise the user is logged out and `@current_user` will be `nil`.
2. The line `helper_method :current_user` makes `current_user` method available in the views. By default, all methods defined in Application Controller are already available in the controllers.   
3. The `require_user` method uses the `current_user` method to redirect logged out users to the login page.

Read more about the `||=` syntax [in this Stack Overflow post](https://stackoverflow.com/questions/995593/what-does-or-equals-mean-in-ruby). 

For more insight into using the `unless` keyword, read [this blog post](https://signalvnoise.com/posts/2699-making-sense-with-rubys-unless).


Filters

Congratulations! You built an authentication system from scratch. What can we generalize so far?

* An authentication system is made up of sign up, log in, log out functionality.
* The `password_digest` column and `has_secure_password` method are provided by bcrypt to store passwords securely. 
* A *session* begins when a users logs in, and ends when a user logs out. 
* The `current_user` method allow us to access the current user; `require_user` redirects to the root of the app if there is no such user. 
* Before actions act as filters. They call methods before executing controller actions. 

Generalizations

Nice job! Now when you fill in the signup form and submit it, the data is sent to the Rails app via a POST request. The request hits the User controller's `create` action. The `create` action saves the data, creates a new session, and redirects to the albums page.

How is a new session created? Sessions are stored as key/value pairs. In the `create` action, the line

```ruby
session[:user_id] = @user.id 
```

creates a new session by taking the value `@user.id` and assigning it to the key `:user_id`.

Users

Nice work! You've added columns to the users table and ran a migration to update the database.

What's the `password_digest` column for? When a user submits their password, it's not a good idea to store that password as is in the database; if an attacker somehow gets into your database, they would be able to see all your users' passwords.

One way to defend against this is to store passwords as encrypted strings in the database. This is what the `has_secure_password` method helps with - it uses the bcrypt algorithm to securely hash a user's password, which then gets saved in the `password_digest` column.

Then when a user logs in again, `has_secure_password` will collect the password that was submitted, hash it with bcrypt, and check if it matches the hash in the database. 

Signup I

What did we just do?

1. We created a model named User.
2. In the model, we used the method `has_secure_password`. This method adds functionality to save passwords securely.
3. In order to save passwords securely, `has_secure_password` uses an algorithm called `bcrypt`.

Now that the User model is set up, let's continue by adding columns to the migration files. 

User Migration

Great work so far! We've built an authentication system that lets new users sign up for the site, and lets existing users log in and out.

However, there's one problem - even after you log out, you can still access the albums page. Why does this happen? Let's look at the request/response cycle:

1. Currently, when a user visits the URL /albums, the browser first makes a request for that URL.
2. The request hits the Rails router.
3. The router sends the request to the Albums controller's `index` action *regardless of whether a user is logged in*.

What we want instead, is for only users who are logged in to see the albums page; otherwise, they should be redirected to the login page. This means that we need to check whether a user is logged in before sending her request on to the Albums controller's `index` action. Let's see how to do this.


current_user

Great! When you visit the URL `/signup`, the browser makes a GET request for the URL. This request hits the Users controller's `new` action, which returns a view displaying the signup page.

Signup II

Now that users can sign up for a new account, let's add the ability to log in and log out of the app. Using the request/response cycle as a guide again, here's how logging in and logging out fits in.

**Turn one:**
1. When the user visit the login page, the browser makes a GET request for the URL `/login`. 
2. The Rails router maps the URL `/login` to the Sessions controller's `new` action. The `new` action handles the request and passes it on to the view. 
3. The view displays the login form. 

**Turn two:**
1. When the user fills in and submits the form, the browser sends the data via a POST request to the app.
2. The router maps the request to the Sessions controller's `create` action. 
3. The `create` action verifies that the user exists in the database. If the user exists, the `create` action logs the user in by creating a new session. Otherwise, it reloads the login page.

Login I

Many web apps let users sign up for a new account and log in and out of their accounts. Together, signing up, logging in and logging out make up an authentication system.

Let's create an authentication system for a photosharing website built with Ruby on Rails.

If you're new to Rails, we recommend you do [our introductory Rails course](https://www.codecademy.com/learn/learn-rails) first.

Nice job! Now when you fill in the login form and submit it, the data is sent to the Rails app via a POST request. The request hits the Sessions controller's `create` action. The `create` action checks whether your email and password exist in the database, creates a new session, and redirects to the albums page.
