Skip to content

joao-mambelli/DesafioStone

Repository files navigation

DesafioStone

Simple ASP.NET Core Web API to manage Invoices.

Getting started

If you want to run the code locally, you need 2 environment variables: Secret and ConnectionString.

  • Secret: The key that will be used to encrypt the tokens generated by the API.
  • ConnectionString: The connection string to your data base.

These can be set in the appsettings.json in the root folder of the main project. Or they can be set as an Environment Variable in your system.

Note that the code will prioritize variables set in the appsettings.json rather than as System Environment Variables. This way you can change them easily for debugging and testing.

To set them as System Environment Variable on Windows you can press Windows + R and run this: "rundll32 sysdm.cpl,EditEnvironmentVariables". Click on "New..." and add them as DesafioStoneSecret and DesafioStoneConnectionString respectively.

Access

Live

Currently, for example purposes, the API is ruinning on a Google Cloud Run instance from a Google Container Registry image. Its image was created using Docker targeting Linux.

You can see its Swagger here: https://desafiostone-nmkn24bkqq-rj.a.run.app/swagger/index.html.

To make API requests to the api from external sources such as Postman, refer to the Swagger and simply use the https://desafiostone-nmkn24bkqq-rj.a.run.app/{endpoints...}

My Google Cloud free trial period has ended, so it's not live anymore.

Who can access it?

The only fully authorized endpoint is the "v1/login" one, which is used to validate the User; generating the 2-hour Bearer token and the refresh token.

To refresh the Bearer token and the refresh token you need to provide the refresh token in the body. Keep in mind that you need to do the refresh before the current token expires, otherwise you will need to login again.

All the Invoice endpoints are accessible with at least an User role token.

The API now has a custom token generation/validation. It will use the Secret, the user's password hash and the "lastLogoutAllRequest" (number of seconds since epoch) to compose the key that will sign the token. This way, if the user changes his/her password, or he/she asks for a "Logout All Devices", all the previous generated tokens will be invalidated. This will require the user to do login after changing the password, tho. Which in my opinion isn't a bad thing.

This approach has a con: It will request the user's information on every request made. This is necessary because we need to get the user's password hash and "lastLogoutAllRequest", which will be used to try to decrypt the token. In my opinion it's worth it because now we have a solid user security.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published