samsch

Stop using JWTs!

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 JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions

samsch

There is no such thing as stateless authentication

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.

Where does my state go?

samsch

Some links

• https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
• https://movingfast.io/articles/environment-variables-considered-harmful/
  • HN: first comment offers a rebuttal, but the first child comment of that explains what's wrong with that rebuttal: https://news.ycombinator.com/item?id=8826024
• Example where the leak wasn't a security issue in the specific case, but could very easily have been (leaked encryption key): https://exceptionshub.com/php-laravel-environment-variables-leaking-between-applications-when-they-call-each-other-through-guzzlehttp.html

A simple alternative is to put your sensitive (or all) config in a .json file that is gitignored. This also has the advantage of being easily generated using tools which can retrieve the sensitive data from a secure store (e.g., via ssh using user ssh key). With Node.js, .json files can be directly require()d, which is an additional convenience.

samsch

When should I use relational vs NoSQL databases?

What is the task you need to accomplish?

Frequently this question is asked as a "what should I use for a web app" question with no real details for what kind of data is being stored. As it turns out, that's ok! We actually have a type of database which directly fits "general purpose", by being fully robust and flexible. These are the relational databases, which are designed around the SQL standard.

Because "general purpose" covers most tasks really well when it comes to databases (something that's not nearly as true in other areas of technology), you can just grab PostgreSQL or MySQL and use that for all data storage purposes, and likely have no issues for the full lifetime of the project.

When general purpose is not enough

samsch

Common issues

Multiple origins

By default, the cookies express-session sets will not work if your server's url isn't the same origin as your front end page where you are making requests from. For example, if you are using Create React App's server on localhost:3000, and your server is running at localhost:8000, cookies won't be saved without extra configuration for CORS.

If you can avoid multiple origins, I recommend doing that. A single origin avoids CORS configuration which tends to be troublesome. Most front end build tools (including Create React App) have options to proxy requests to your backend server. Even better are tools which build your front end to files that can be directly served by your backend (such as using Parcel's watch command).

The CORS configuration will include:

• Setting SameSite on your cookie options to none.

samsch

Why React Data Fetching is Hard (right now)

Context

Recently Dan Abramov has been linking drafts of a new documentation page for useEffect, which has kicked off discussion about where you are "supposed" to do data fetching in a "React app". Some of that conversation is happening on Twitter such as here: https://twitter.com/dan_abramov/status/1532540685710147589

Within the draft and repeated on Twitter, there is a recommendation that for data fetching you should use third party libraries as either tools like React Query or useSWR or via frameworks such as Next and Remix which include integrated data fetching solutions. Writing your own data fetching using useEffect is suggested to be only a fallback in case you can't do those things, and not really a preferred recommendation.

This idea is hitting backlash, with a basic detracting idea that boils down to: React is a client side framework, how can it not include as a feature an important and common requirement like data loading.

samsch

knex
  .select([
    'users.*',
    knex.raw('json_agg("posts") as posts')
  ])
  .from('users')
  .leftJoin(function () {
    this.select(['posts.*', knex.raw('json_agg("comments") as comments')])
      .from('posts')
      .leftJoin('comments', { 'posts.id': 'comments.post' })

samsch

Start a postgres server:

docker run -v postgres:/var/lib/postgresql/data --name postgres-test -e POSTGRES_PASSWORD=mysecretpassword -d postgres

Start pgadmin

Connect with a one-off docker container in current process:

docker run -v pgadmin4:/home/pgadmin/.pgadmin -p 5050:5050 --link postgres-test:postgres-test --rm meedan/pgadmin

samsch

#!/bin/bash

name=$1

if [[ -n "$name" ]]; then
    if [[ $name =~ ^[a-z_]+$ ]]; then
        sudo -u postgres createdb $name
        sudo -u postgres createuser $name
        sudo -u postgres psql -c "alter user $name with encrypted password '$name';"
        sudo -u postgres psql -c "grant all privileges on database $name to $name;"

samsch

All Data is Relational

Think of the least relational data you can come up with.

That data, and each item in it, has explicit and implicit relationships.

If it's a list of items, then the items are explicitly related to each other by nature of being in the same list. A list is a type of relationship.

If you have an app that stores random items which are each completely unrelated to each other... they are all related to the app.