JWT Authentication - middlewares

[zannis]

We need to add the JWT authorization middlewares to the following endpoints: At the right side you see the user roles that can access each endpoint

GET /users < ['user-ngo', 'user-independent', 'admin'] GET /users/:id < ['user-ngo', 'user-independent', 'admin'] PUT /users/:id < ['admin'] DELETE /users/:id < ['admin']

GET /ngos < ['user-ngo', 'user-independent', 'admin'] GET /ngos/:id < ['user-ngo', 'user-independent', 'admin'] POST /ngos < ['user-ngo', 'admin'] PUT /ngos/:id < ['admin'] DELETE /ngos < ['admin']

The following endpoints will NOT have JWT middlewares:

POST /auth/login POST /users

We will do it the following way:

Add the express-jwt library to the project and call it in all of the endpoints in the first list above. The middleware will get the JWT_SECRET_KEY variable from the .env file. (If #46 is merged before this is implemented, look at the .env file for the actual variable name.) This middleware will expose the JWT payload inside a property called 'user' inside the request object. We will then create a second middleware called validateRoles() which will take a parameter, which will be an array of roles that can access the endpoint. For now, our available roles will be ['user-ngo', 'user-independent', 'admin'] This middleware will access the req.user object and look to find the 'role' property inside the provided array. If it does, we call next(), otherwise we will throw a 403 error with the body

{
    errror: 'You are unauthorized to access this resource.'
}

Acceptance criteria:

1. Update the user schema, to set the roles of the user entity to be: ['user-ngo', 'user-independent', 'admin']
2. Include the express-jwt (and jsonwebtoken if necessary) libraries to the project
3. Update all mentioned endpoints to call the express-jwt middleware with the secret key variable
4. Implement a second middleware called validateRoles that takes a roles array as a parameter and checks that the req.user.role exists in the array. If so, call next, otherwise throw error.
5. Add the validateRoles() middleware to all necessary endpoints with the correct roles array as its parameter

[bbouba]

So the middleware validateRoles() will be define on the route.js file or in a separate file?

[zannis]

Let's use a separate file.

On Sat, Jun 27, 2020, 12:35 AM bbouba notifications@github.com wrote:

So the middleware validateRoles() will be define on the route.js file or in a separate file?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SocialHackersClass10/ChalleduApp/issues/59#issuecomment-650413749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHW567PV4XAI4L3PTMFYJTRYUIB7ANCNFSM4OJC3ZYA .

[student0b4dc0d3]

@SocialHackersClass10/team-class-10 @zannis

Baring the existence of any unforeseen and/or undisclosed requirements, I feel we could benefit in simplifying this process by dropping the role-distinction between users that are ngo-rep and freelancer. My thought on this was as follows: on the upper documentation there seems to exist only one point of such distinction, which at said point is invalid, since by the time a user reaches the POST of an NGO, that user would already exist in the database as a "user" but not as a "representative", since the NGO they represent doesn't exist (in our datastore) yet. Thus, IMHO , and baring any aforementioned cases of exceptions, we could simplify by minimizing the roles to "user" and "admin". Whether a user is a rep or a freelancer can be determined on whether or not they have values assigned to affiliated_ngo part of the document.

For your consideration Thank you and have a great afternoon

[zannis]

My only objection to this lies in the requirement where an independent user should not be able to create an NGO profile and we need a way to distinguish this in the frontend.

And the role is chosen during registration so it should not be changed past that point.

On Mon, Jun 29, 2020, 2:44 PM student0b4dc0d3 notifications@github.com wrote:

@SocialHackersClass10/team-class-10 https://github.com/orgs/SocialHackersClass10/teams/team-class-10 @zannis https://github.com/zannis

Baring the existence of any unforeseen and/or undisclosed requirements, I feel we could benefit in simplifying this process by dropping the role-distinction between users that are ngo-rep and freelancer. My thought on this was as follows: on the upper documentation there seems to exist only one point of such distinction, which at said point is invalid, since by the time a user reaches the POST of an NGO, that user would already exist in the database as a "user" but not as a "representative", since the NGO they represent doesn't exist (in our datastore) yet. Thus, IMHO , and baring any aforementioned cases of exceptions, we could simplify by minimizing the roles to "user" and "admin". Whether a user is a rep or a freelancer can be determined on whether or not they have values assigned to affiliated_ngo part of the document.

For your consideration Thank you and have a great afternoon

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SocialHackersClass10/ChalleduApp/issues/59#issuecomment-651061882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHW5652GOB2ZFSOB3F2GA3RZB5C7ANCNFSM4OJC3ZYA .

[student0b4dc0d3]

I see, thank you for clearing this up for me, I had a somewhat murky view altogether on this topic.

[bbouba]

That mean, we don't need to update schema there we alredy have this roles ['administrator', 'User'] ?

[zannis]

No let's update this as described in the description.