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

[crysfel]

I'm not sure if we should commit these files and if so.... is there a way to put them somewhere else other than the root folder?

These files are created automatically when deploying with the serverless framework.

[crysfel]

This is my first time working with serverless and I have some questions for those of you who know all the ins and outs of this technology :)

[crysfel]

These data is defined in azure as Application Settings, everything works great except for AUTH0_CERTIFICATE. For now I hardcoded the value of this variable in the azure console, which is not ideal.

The value of this variable is something like:

AUTH0_CERTIFICATE = `
-----BEGIN CERTIFICATE-----
ABC123.....
ABC123.....
ABC123.....
-----END CERTIFICATE-----`

It looks like when saving this value in the applications settings azure removes the \n and when used in the code doesn't work :(

Anyone can help me with this?

[crysfel]

Another question I have is that every time I deploy... these values disappear in azure :( and I need to add it again, if I deploy a single function everything works as expected.

Anyone knows how to prevent that? Or how can we dynamically create those settings?

[davisokoth]

Hi @crysfel, am not sure if these can be handled in the local.settings.json

[swissarmykirpan]

you could set these variables in the serverless.yml

[crysfel]

I would like to make this as post instead of get and I'd like to use the path /users. Anyone can help me with that?

[swissarmykirpan]

this is done in the function.json, there should be a function.json per function handler - since you are using serverless, there should be some config in the handler in the serverless.yml that allows you to specify this

[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