| exception ZaapError { | |
| 1: required i32 code, | |
| 2: optional string details | |
| } | |
| enum ErrorCode { | |
| UNKNOWN = 1, | |
| UNAUTHORIZED = 2, | |
| INVALID_GAME_SESSION = 3, | |
| CONNECTION_FAILED = 1001, |
| const crypto = require("crypto") | |
| // The `generateKeyPairSync` method accepts two arguments: | |
| // 1. The type ok keys we want, which in this case is "rsa" | |
| // 2. An object with the properties of the key | |
| const { publicKey, privateKey } = crypto.generateKeyPairSync("rsa", { | |
| // The standard secure default length for RSA keys is 2048 bits | |
| modulusLength: 2048, | |
| }) |
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:
I use this gist to keep track of the important software and steps required to have a functioning system after a semi-annual fresh install. On average, I reinstall each computer from scratch every 6 months, and I do not perform upgrades between distros.
This keeps the system performing at top speeds, clean of trojans, spyware, and ensures that I maintain good organizational practices for my content and backups. I highly recommend this.
You are encouraged to fork this and modify it to your heart's content to match your own needs.
| #!/usr/bin/env bash | |
| # | |
| # Bootstrap script for setting up a new OSX machine | |
| # | |
| # This should be idempotent so it can be run multiple times. | |
| # | |
| # Some apps don't have a cask and so still need to be installed by hand. These | |
| # include: | |
| # | |
| # - Twitter (app store) |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j