Chapter 04 corrigé Lorène

Author: madeindjs

rails6/en/chapter04-athentification.adoc

@@ -12,7 +12,7 @@ You can clone the project up to this point:
 $ git checkout tags/checkpoint_chapter04
 ----
 
-In this chapter things will get very interesting because we are going to set up our authentication mechanism. In my opinion this is going to be one of the most interesting chapters. We will introduce a lot of new terms and you will end with a simple but powerful authentication system. Don’t feel panic we will get to that.
+In this chapter things will get very interesting because we are going to set up our authentication mechanism. In my opinion it's one of the most interesting chapters. We will introduce a lot of new terms and you will end with a simple but powerful authentication system. Don’t feel panic we will get to that.
 
 First things first (and as usual when starting a new chapter) we will create a new branch:
 
@@ -29,11 +29,11 @@ The flow for authenticating the user through an API is very simple:
 
 . The client request for `sessions` resource with the corresponding credentials, usually email and password.
 . The server returns the `user` resource along with its corresponding authentication token
-. Every page that requires authentication, the client has to send that `authentication token`
+. For every page that requires authentication the client has to send that `authentication token`
 
-Of course this is not the only 3-step to follow, and even on step 2 you might think, well do I really need to respond with the entire user or just the `authentication token`, I would say, it really depends on you, but I like to return the entire user, this way I can map it right away on my client and save another possible request from being placed.
+Of course this is not the only 3-step to follow, and even on step 2 you might think, well do I really need to respond with the entire user or just the `authentication token` ? I would say, it really depends on you, but I like to return the entire user, this way I can map it right away on my client and save another possible request from being placed.
 
-In this section and the next we will be focusing on building a Sessions controller along with its corresponding actions. We’ll then complete the request flow by adding the necessary authorization access.
+This section and the next we will be focusing on building a Sessions controller along with its corresponding actions. We’ll then complete the request flow by adding the necessary authorization access.
 
 
 === JWT presentation
@@ -44,9 +44,9 @@ When it comes to authentication tokens, there is a standard: the JSON Web Token
 
 Overall, a JWT token is composed of three parts:
 
-- a *header* structured in JSON which will contain for example the validity date of the token.
-- a _payload_ structured in JSON that can contain *any data*. In our case, it will contain the identifier of the "connected" user.
-- a *signature* that will allow us to verify that the token has been encrypted by our application and is therefore valid.
+- a *header* structured in JSON contains for example the validity date of the token.
+- a _payload_ structured in JSON can contain *any data*. In our case, it will contain the identifier of the "connected" user.
+- a *signature* allows us to verify that the token has been encrypted by our application and is therefore valid.
 
 These three parts are each encoded in base64 and then concatenated using points (`.`). Which gives us something like that:
 
@@ -71,7 +71,7 @@ Once decoded, this token gives us the following information:
 
 NOTE: For more information about JWT tokens I invite you to visit https://jwt.io[jwt.io]
 
-This has many advantages such as sending information in token's payload. For example, we may choose to integrate the user's information into the _payload_.
+This has many advantages such as sending information in token's payload. For example, we may choose to integrate user's information into the _payload_.
 
 === Setting up the authentication token
 
@@ -100,9 +100,9 @@ The library is very simple. There are two methods: `JWT.encode` and `JWT.decode`
  => [{"message"=>"Hello World"}, {"alg"=>"HS256"}]
 ----
 
-In the first line we encoded a _payload_ with the secret key _my_secret_key_. So we get a token that we can simply decode. The second line decodes the token and we see that we find our _payload_ well.
+In the first line we encoded a _payload_ with the secret key _my_secret_key_. So we get a token we can simply decode. The second line decodes the token and we see that we find our _payload_ well.
 
-We will now include all this logic in a `JsonWebToken` class in a new file located in `lib/`. This will allow us to avoid duplicating the code.  This class will just encode and decode the JWT tokens. So here is the implementation.
+We will now include all this logic in a `JsonWebToken` class in a new file located in `lib/`. This will allow us to avoide duplicating the code.  This class will just encode and decode the JWT tokens. So here is the implementation.
 
 .lib/json_web_token.rb
 [source,ruby]
@@ -124,8 +124,8 @@ end
 
 I know that's a lot of code but we're going to review it together.
 
-- the method `JsonWebToken.encode` will take care of encoding the _payload_ by adding an expiration date of 24 hours by default. We also use the same encryption key as the one configured with Rails
-- the method `JsonWebToken.decode` will decode the JWT token and get the _payload_. We then use the https://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html[`HashWithIndifferentAccess`] class provided by Rails which allows us to retrieve a value of a `Hash` with a `Symbol` or `String`.
+- the method `JsonWebToken.encode` takes care of encoding the _payload_ by adding an expiration date of 24 hours by default. We also use the same encryption key as the one configured with Rails
+- the method `JsonWebToken.decode` decodes the JWT token and gets the _payload_. Then we use the https://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html[`HashWithIndifferentAccess`] class provided by Rails which allows us to retrieve a value of a `Hash` with a `Symbol` or `String`.
 
 There you go. In order to load the file into our application, you must specify the `lib` folder in the list of Ruby on Rails _autoload_s. To do this, add the following configuration to the `application.rb` file:
 
@@ -151,7 +151,7 @@ $ git add . && git commit -m "Setup JWT gem"
 
 === Token's controller
 
-We have therefore set up the system for generating a JWT token. It is now time to create a route that will generate this token. The actions we will implement will be managed as _RESTful_ services: the connection will be managed by a POST request to the `create` action.
+We have therefore set up the system for generating a JWT token. It's now time creating a route that will generate this token. The actions we will implement will be managed as _RESTful_ services: the connection will be managed by a POST request to the `create` action.
 
 To start, we will start by creating the controller of and method `create` in the _namespace_ `/api/v1`. With Rails, one order is sufficient:
 
@@ -238,7 +238,7 @@ Failure:
 Expected response to be a <401: unauthorized>, but was a <204: No Content>
 ----
 
-That's normal. It is now time to implement the logic to create the JWT token. It is very simple.
+That's normal. It's now time implementing the logic to create the JWT token. It is very simple.
 
 .config/routes.rb
 [source,ruby]
@@ -267,10 +267,10 @@ end
 
 That's a lot of code but it's very simple:
 
-. We always filter the parameters with the method `user_params`.
+. We always filter parameters with the method `user_params`.
 . We retrieve the user with the method `User.find_by_email` (which is a "magic" method of _Active Record_ since the field `email` is present in the database) and we retrieve the user
 . We use the method `User#authenticate` (which exists thanks to the gem `bcrypt`) with the password as a parameter. Bcrypt will _hash_ password and check if it matches the attribute `password_digest`. The function returns `true` if everything went well, `false` if not.
-. In the case where the password corresponds to the _hash_, a JSON containing the _token_ generated with the class `JsonWebToken` is returned. Otherwise, an empty response is returned with an `unauthorized` header
+. If the password corresponds to the _hash_, a JSON containing the _token_ generated with the class `JsonWebToken` is returned. Otherwise, an empty response is returned with an `unauthorized` header
 
 Are you still here? Don't worry, it's over! Now your tests must pass.
 
@@ -296,13 +296,15 @@ $ git add . && git commit -m "Setup tokens controller"
 
 So we implemented the following logic: API returns the authentication token to the client if credentials are correct .
 
-We will now implement the following logic: Each time this client requests a protected page, we will have to find the user from this authentication token that the user has passed in the HTTP header.
+We will now implement the following logic: Each time this client requests a protected page, we'll have to find the user from this authentication token that the user has passed in the HTTP header.
+
+//pas compris
 
 In our case, we will use the HTTP header `Authorization` which is often used for this. Personally, I find it the best way because it gives context to the request without polluting the URL with additional parameters.
 
 We will therefore create a `current_user` method to meet our needs. It will find the user thanks to his authentication token which is sent on each request.
 
-When it comes to authentication, I like to add all the associated methods in a separate file. Then simply include the file in the `ApplicationController`. In this way, it is very easy to test in isolation. Let's create the file in the `controllers/concerns` directory with a `current_user` method that we will implement right after:
+When it comes to authentication, I like adding all the associated methods in a separate file. Then simply include the file in the `ApplicationController`. In this way, it's very easy to test in isolation. Let's create the file in the `controllers/concerns` directory with a `current_user` method that we will implement right after:
 
 [source,ruby]
 .app/controllers/concerns/authenticable.rb
@@ -323,7 +325,7 @@ $ mkdir test/controllers/concerns
 $ touch test/controllers/concerns/authenticable_test.rb
 ----
 
-As usual, we start by writing our tests. In this case, our `current_user` method will search for a user by the authentication token in the HTTP header `Authorization`. The test is quite basic:
+As usual, we start by writing our tests. In this case, our `current_user` method will search for an user by the authentication token in the HTTP header `Authorization`. The test is quite basic:
 
 [source,ruby]
 .test/controllers/concerns/authenticable_test.rb
@@ -444,7 +446,7 @@ $ git add . && git commit -m "Adds authenticable module for managing authenticat
 
 == Authentication with the token
 
-Authorization plays an important role in the construction of applications because, unlike authentication, which identifies the user, authorization helps us define what he or she is allowed to do.
+Authorization plays an important role in the construction of applications because it helps us define what user is allowed to do.
 
 We have a route to update the user but there is a problem: anyone can update any user. In this section, we will implement a method that will require the user to be logged in to prevent unauthorized access.
 
@@ -477,7 +479,7 @@ class Api::V1::UsersControllerTest < ActionDispatch::IntegrationTest
 end
 ----
 
-You can see that now we have to add a header _Authorization_ for the user's modification action. We want to receive a _forbidden_ response if we don't .
+You can see now we have to add a header _Authorization_ for the user's modification action. We want to receive a _forbidden_ response if we don't .
 
 We can imagine about the same thing for the test _should forbid destroy user_: