(C-x means ctrl+x, M-x means alt+x)
The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf
:
#!flask/bin/python | |
from flask import Flask, jsonify, abort, request, make_response, url_for | |
from flask_httpauth import HTTPBasicAuth | |
app = Flask(__name__, static_url_path = "") | |
auth = HTTPBasicAuth() | |
@auth.get_password | |
def get_password(username): | |
if username == 'miguel': |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
The big "make everything stateless" hype is just that: hype. Your server-side application code, should usually be stateless, because this makes your application more resilient to errors, easier to scale, and easier to reason about. But there are exceptions to even that, especially for stuff like video game servers.
Your services are almost always going to be stateful, and should be. If you have a database, files, or literally anything that affects the responses the server sends, then the service is not stateless.
So building "stateless" services is a lie. You shouldn't strive to make your services stateless, you should make sure you're putting your state in the correct place.