Update session-management.md

Spelling

node-js/session-management.md

@@ -12,16 +12,16 @@ When our backend application receives a HTTP request from the client, how can th
 
 One solution for this problem is to let the browser send the user's credentials (username and password) in every request. This way, we can authenticate and identify the user in every request. Sending the secret credentials in every request can be implemented with [Basic HTTP Authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication). It is generally not a good idea to use this method due to security concerns.
 
-A better solution is for the application to issue a secret `session ID` (Also called `token` or `access token`) after a successful login. This session ID is a long random string that does not makes sense to the user. The server has a connection between the session ID and the user itself. After login, the user will send only his session ID to the server in order to proof his identity. 
+A better solution is for the application to issue a secret `session ID` (Also called `token` or `access token`) after a successful login. This session ID is a long random string that does not makes sense to the user. The server has a connection between the session ID and the user itself. After login, the user will send only their session ID to the server in order to prove their identity. 
 
-Using a session ID is very flexible because we can delete it and add features like expiration date.
+Using a session ID is very flexible because we can delete it and add features like an expiration date, making the user log in again after their session expires.
 
 ### Creating a session (login)
 
 First, let's try to implement the `/login` endpoint and allow our users to authenticate to the application and receive the session ID.
 
 In the following diagram, we show the general login process to implement:
-![Login diagram](/node-js/assets/login-diagram.png)
+![Login diagram](./assets/login-diagram.png)
 
 
 Note: We assume that there is already a way for users to register and we have a user database to check for valid passwords. We explain that part in the [User Registration](/node-js/user-registration.md) section.
@@ -61,10 +61,10 @@ This unique ID was generated by the built-in [`randomUUID()`](https://developer.
 
 This unique session ID is saved in our session database and connected to a specific user. The connection is made with this line: `sessions[sessionId] = username;`.
 
-For the next request, the user is no longer require to send his credentials, it is enough to send the session ID and the server will know the connected username.
+For the next request, the user is no longer required to send their credentials, it is enough to send the session ID and the server will know the connected username.
 
 #### What should the client do with the session Id?
-The client (browser in our case), should save the session ID for future requests. This session ID is secret and should not be shared with anyone. One option to is to save the session ID in [`localStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) or [`sessionStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage).
+The client (browser in our case), should save the session ID for future requests. This session ID is secret and should not be shared with anyone. The most common option is to save the session ID in [`localStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) or [`sessionStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage).
 
 ### Creating protected endpoints
 
@@ -90,12 +90,12 @@ app.get('/profile', async (req, res) => {
 });
 ```
 
-This code is using the session ID sent by the client to connect the HTTP request to a specific user. After the connection is made, this endpoint can perform personalized action for this specific user like returning his private messages. In our case, we just return a nice success message with the username.
+This code is using the session ID sent by the client to connect the HTTP request to a specific user. After the connection is made, this endpoint can perform personalized action for this specific user like returning their private messages. In our case, we just return a nice success message with the username.
 
 #### How should the client send the session ID?
-There are many ways that the client can send us back the session ID. Some applications using `cookies`, others use `HTTP Headers`. You can even pass the session ID in the URL.
+There are many ways that the client can send us back the session ID. Some applications use `cookies`, others use `HTTP Headers`. You can even pass the session ID in the URL.
 
- In our example, we will a special [HTTP Authorization header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization). This header follows the following format:
+In our example, we will use a special [HTTP Authorization header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization). This header follows the following format:
 
 ```Authorization: <auth-scheme> <authorization-parameters>```
 
@@ -143,11 +143,11 @@ app.post('/logout', async (req, res) => {
 });
 ```
 
-To logout a user, we simply delete his session ID from the sessions database. Now that the session ID is deleted, it can no longer be used by the client to access any protected endpoint. The client will have to authenticate again to receive a new session ID.
+To logout a user, we simply delete their session ID from the sessions database. Now that the session ID is deleted, it can no longer be used by the client to access any protected endpoint. The client will have to authenticate again to receive a new session ID.
 
 ## Opaque token vs JSON Web Token (JWT)
 ### Opaque token
-In the previous section, we used a `session ID` to identify users. This Session ID is completely random string which is hard to guess. Because it is completely random and the client cannot get any information out of it, we call this an `Opaque token`.
+In the previous section, we used a `session ID` to identify users. This Session ID is a completely random string which is hard to guess. Because it is completely random and the client cannot get any information out of it, we call this an `Opaque token`.
 
 The disadvantage using an `Opaque token` is the extra work the server has to do in order to translate the token into the user. 
 
@@ -175,11 +175,11 @@ If we do not verify that the session is real, a user can fake the session token
 
 ### JWT
 
-[JWT (JSON Web Token)](/node-js/jwt-tokens.md) is solving the issue of verification. With JWT, it is possible to add information to our token in a way that the server can verify the token without accessing the session database.
+[JWT (JSON Web Token)](/node-js/jwt-tokens.md) is solving this issue of verification. With JWT, it is possible to add information to our token in a way that the server can verify the token without accessing the session database.
 
 Read more about JWT in [JWT section](/node-js/jwt-tokens.md) 
 
 
 
 ## Further reading
-* [Express Session](https://github.com/expressjs/session)
+* [Express Session](https://github.com/expressjs/session)