Protecting endpoints with a middleware

[crysfel]

Description

This PR adds a middleware to check if there's a JWT in the header, it tries to extract the data and put it inside the request.

If there's not a valid JWT (Or missing) the middleware returns an error and completes the request. If everything is OK, then it continues the execution of the function.

I've created two endpoints:

• /users: list all users, for now it only returns dummy data but this data is protected.
• /users-add: Request the current user's information from auth0, this endpoint will save the new user in the database. For now is only returning the user's information in the response but later on we will get the email, name, avatar, etc. and save it in the database when a new user signs up.

Closes #44

[swissarmykirpan]

a few comments:

1. If we are going graphql - then we dont need to protect these endpoints - what we need to do is create a graphql azure function and then protect that.
2. AzureAPIM can do the protection piece. I can register Auth0 as an 0auth provider in Azure APIM and it will do the validation of the JWT and handle rejection. It's also cool because you can do a lot more with it (throttling, policies etc) - and it works on the consumption model (same as azure functions). We can also get AzureAPIM to turn the JWT into an object we can use, and pass that down to the graphql azure function
3. Then all we have to do in the azure function is deserialize the json into an object and we're done.
4. We don't really need serverless since the azure cli does all of that work for us in combination with the function.json

[crysfel]

1. If we are going graphql - then we dont need to protect these endpoints - what we need to do is create a graphql azure function and then protect that.

That's coming next, right now we need to a simple REST endpoint that we can use with the alpha version, for the final product we will have graphql for sure. We want to have a basic backend where we can save user's profile information and another one to search/filter.

2. AzureAPIM can do the protection piece. I can register Auth0 as an 0auth provider in Azure APIM and it will do the validation of the JWT and handle rejection. It's also cool because you can do a lot more with it (throttling, policies etc) - and it works on the consumption model (same as azure functions). We can also get AzureAPIM to turn the JWT into an object we can use, and pass that down to the graphql azure function

This sounds cool, let's do that next when graphql is integrated.

[swissarmykirpan]

1. If we are going graphql - then we dont need to protect these endpoints - what we need to do is create a graphql azure function and then protect that.

That's coming next, right now we need to a simple REST endpoint that we can use with the alpha version, for the final product we will have graphql for sure. We want to have a basic backend where we can save user's profile information and another one to search/filter.

I don't think it would take much effort to get the graphql azure function in - once we have agreed on what an ideal azure function looks like.

Do we have any specific detailed requirements about search/filter at this stage? More and more I get the feeling we should store everything in a Graph Db

1. AzureAPIM can do the protection piece. I can register Auth0 as an 0auth provider in Azure APIM and it will do the validation of the JWT and handle rejection. It's also cool because you can do a lot more with it (throttling, policies etc) - and it works on the consumption model (same as azure functions). We can also get AzureAPIM to turn the JWT into an object we can use, and pass that down to the graphql azure function

This sounds cool, let's do that next when graphql is integrated.

Yup that's cool

[crysfel]

Do we have any specific detailed requirements about search/filter at this stage? More and more I get the feeling we should store everything in a Graph Db

For now we only need a few filters:

• By technology
• By name
• By country
• By favorite mentors

[crysfel]

I don't think it would take much effort to get the graphql azure function in - once we have agreed on what an ideal azure function looks like.

That's cool, however we don't want to add many updates to the alpha app, all we want is to call a REST endpoint to add a new user as a mentor and another one to do the filtering. Graphql will be used for the final product, but not in the alpha version we already have