reading notes for code fellows
These are important topics when learning about security and authentication for our apps and site as we continue developing them.
A JSON Web Token(JWT) is an open standard that defines a compact and self-contained way to transmit digitally signed info between parties as JSON. JWT’s do have the option to be encrypted, but signed tokens can verify the integrity of the claims it contains whereas the encrypted tokens hide the claims. JWTs are very useful for authorization and information exchange. A JWT is made up of a header, which contains the type of token and the signing algorithm being used, the oayload, which contains the claims, and the signature, which is comprised of the encoded header and payload, a scret, and the algorithm specified in the header, then signed. The JWT itself appears as 3 base64 strings separated by .’s. JSON is good for use in HTML environments since it is so compact, and has a more simple signing method than other possibilities.
A JWT is aquired by exchanging a username and password for an access (short term, expires in around 5 minutes) and refresh (expires in 24 hours) token. After the refresh token expires, you will need to login again, though both lengths are customizable. When using these tokens, you will need to authenticate and obtain the token with POST, then store the access and refresh tokens in the client side localStorage. To access protected views, the access token should be included in the header of requests. To get a new access token after it expiresm you can use the refresh token endpoint to get back a new access token.
python manage.py runserver is good for development convenience, but it’s not meant to be used in production setup. It doesn’t have good performance and hasn’t been built with any mind to security concerns. A normal production setup consists of multiple components, each designed to be good at one specific thing. When a request arrives at your server, it should be passed to a dedicated webserver, which is an app that is great at serving static files from your disc and handling multiple requests at once. If the webserver is not the right component for the job, it is designed to pass on the request to the next one, which is an application server. This can construct Python objects to be usable by Django. Django itself doesn’t actually run, it has a uwsgi.py file that takes care of ‘creating’ Python objects for the application server and sending them back to the web server.
I was unaware about the realities of runserver, and will need to keep that in mind for the future.