Skip to content

Instantly share code, notes, and snippets.

@samsch
samsch / stateless-is-a-lie.md
Created May 14, 2019 18:50
Stateless is a lie

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
samsch / stop-using-jwts.md
Last active May 26, 2024 19:07
Stop using JWTs

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
@ryansimms
ryansimms / circleci-2.0-eb-deployment.md
Last active February 22, 2024 04:55
Deploying to Elastic Beanstalk via CircleCi 2.0

Deploying to Elastic Beanstalk via CircleCi 2.0

I got to here after spending hours trying to deploy to an Elastic Beanstalk instance via CircleCi 2.0 so I thought I'd write up what worked for me to hopefully help others. Shout out to RobertoSchneiders who's steps for getting it to work with CircleCi 1.0 were my starting point.

For the record, I'm not the most server-savvy of developers so there may be a better way of doing this.

Setup a user on AWS IAM to use for deployments

@lorneli
lorneli / benchmark-redis-aof-fysnc
Last active February 19, 2020 16:45
Benchmark redis aof fsync policy
1.Test environment
4core 2gb (use 4core so background fsync thread used by AOF_FSYNC_EVERYSEC can execute on other core)
ubuntu server 14.04
redis-version: 3.2.8
2.Procedure
Disable rdb bgsave, aof rewrite in config to avoid other factors
Set 'appendfsync' entry tto 'no', 'everysec' and 'always' in turn
for each policy:
@tylermakin
tylermakin / ec2-ftp-tutorial.md
Last active March 30, 2024 05:13
Tutorial for configuring FTP access to an EC2 server
@joepie91
joepie91 / sessions.md
Last active May 14, 2024 03:40
Introduction to sessions

While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.

Secure user authentication requires the use of session cookies.

Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.

Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.

*S

@ericelliott
ericelliott / fp-lingo.md
Last active February 2, 2023 23:33
A Guide to Functional Programming Lingo for JavaScripters

A Guide to Functional Programming Lingo for JavaScripters

Functional programming gets a bad wrap about being too hard for mere mortals to comprehend. This is nonsense. The concepts are actually quite simple to grasp.

The jargon is the hardest part. A lot of that vocabulary comes from a specialized field of mathematical study called category theory (with a liberal sprinkling of type theory and abstract algebra). This sounds a lot scarier than it is. You can do this!

All examples using ES6 syntax. wrap (foo) => bar means:

function wrap (foo) {
@hmartiro
hmartiro / zeromq-vs-redis.md
Last active June 17, 2024 14:04
Comparison of ZeroMQ and Redis for a robot control platform

ZeroMQ vs Redis

This document is research for the selection of a communication platform for robot-net.

Goal

The purpose of this component is to enable rapid, reliable, and elegant communication between the various nodes of the network, including controllers, sensors, and actuators (robot drivers). It will act as the core of robot-net to create a standardized infrastructure for robot control.

Requirements:

@jamesob
jamesob / nodejs-question.md
Last active January 26, 2019 22:50
An open question (rant) about node.js

Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n concurrent flows.

After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?

It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed

@consti
consti / hosts
Last active June 7, 2024 13:12
/etc/hosts to block shock sites etc.
# This hosts file is brought to you by Dan Pollock and can be found at
# http://someonewhocares.org/hosts/
# You are free to copy and distribute this file for non-commercial uses,
# as long the original URL and attribution is included.
#<localhost>
127.0.0.1 localhost
127.0.0.1 localhost.localdomain
255.255.255.255 broadcasthost
::1 localhost