While I was preparing the next post, I run into an annoying warning that I wanted to fix before I add one additional feature to the minimalistic to-do application. Let us explore what I had to do to find the reason for the warning and how I could fix the problem.
The HTTP basic authentication from last week has been working, but it feels a bit messy. When we search for a more current style of authentication, we end up with OAuth2 and JWT. There is an example in the FastAPI documentation that I changed a bit to use a different library for JWT, store the secret key in a .env file and use BCrypt to hash the passwords.
There are many ways we can secure an endpoint in FastAPI. As a first approach we explore HTTP basic authentication, a not so secure way but it allows us to get a first glimpse into the different parts of FastAPI that we need to protect an endpoint.
When it comes to authentication, we often find some form of username and password as the backbone of the solution. Before we dive into those examples, I like to make a detour and first explain how we can securely hash passwords in Python. While it is possible to just store passwords as plaintext for an example application, such hacks tend to get into production and that would be a disaster waiting to happen. Let us do it the right way directly from the start and always hash our passwords.
With FastAPI we get the OpenAPI specification and the Swagger interactive documentation for free. While that is a great help, the automatically generated documentation is not always as helpful as it could be. Let us look for ways in which we can fine-tune the documentation.
While improving the HTTP status codes, I noticed that there should be a header pointing to the newly created task. Let us add that header to our FastAPI application.
Our to-do application currently responds with the HTTP status codes 200 when everything is ok and 404 if the requested task does not exist. While this works, it is not as specific as it could be. Let us explore our options when it comes to HTTP status codes.
The basic models we used for our tasks are good to make sure we get the right types. However, if we accept something like int or string, we could get enormously large inputs that are valid strings or numbers but make no sense at all for our application. Let us explore ways to limit our fields to reasonable lengths.
The to-do application started nicely and with the refactoring we got the most obvious code smells fixed. While checking the API in uvicorn, I noticed three missing features that we are going to implement in this post.
Our minimalistic to-do application has collected some code smells. In this post we go through them and refactor our code to keep the application in a maintainable state for the upcoming changes.