Mix.install([
{:plug_cowboy, "~> 2.6"}
])
Application.put_env(:sample, PhoenixDemo.Endpoint, | |
http: [ip: {127, 0, 0, 1}, port: 8080], | |
server: true, | |
live_view: [signing_salt: "bumblebee"], | |
secret_key_base: String.duplicate("b", 64), | |
pubsub_server: PhoenixDemo.PubSub | |
) | |
Mix.install([ | |
{:plug_cowboy, "~> 2.6"}, |
Deploying a Phoenix app to Fly.io is a breeze...is what everyone kept telling me. In fairness, I imagine the process would have been breezier had I just used postgres, but all the sqlite and litestream talk has been far too intriguing to ignore. "Wait", you say. "It is just a flat file. How much harder can it be?"
It is easy to make something harder than it should be. It is hard to take something complex and make it truly simple. flyctl launch
does an amazing job at providing a simple interface to the utterly complex task of generating deployment resources, especially now that we are living in a containerd
(erm, firecracker) world.
This gist is for anyone who, like me, thinks they know better than to read all of the documentation and therefore necessari
/* Using a JavaScript proxy for a super low code REST client */ | |
// via https://dev.to/dipsaus9/javascript-lets-create-aproxy-19hg | |
// also see https://towardsdatascience.com/why-to-use-javascript-proxy-5cdc69d943e3 | |
// also see https://github.com/fastify/manifetch | |
// also see https://github.com/flash-oss/allserver | |
// and https://gist.github.com/v1vendi/75d5e5dad7a2d1ef3fcb48234e4528cb | |
const createApi = (url) => { | |
return new Proxy({}, { | |
get(target, key) { |
matrix = [[1,2,3,4], [5,6,7,8]] | |
defmodule Matrix do | |
def transpose([[] | _]), do: [] | |
def transpose(m) do | |
[Enum.map(m, &hd/1) | transpose(Enum.map(m, &tl/1))] | |
end | |
end | |
IO.inspect matrix |
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
class ApplicationController < ActionController::Base | |
protect_from_forgery with: :exception | |
around_action :global_request_logging | |
def global_request_logging | |
http_request_header_keys = request.headers.env.keys.select{|header_name| header_name.match("^HTTP.*|^X-User.*")} | |
http_request_headers = request.headers.env.select{|header_name, header_value| http_request_header_keys.index(header_name)} | |
puts '*' * 40 | |
pp request.method |
#!/bin/bash | |
# This script provides easy way to debug remote Erlang nodes that is running in a kubernetes cluster. | |
# Usage: ./erl-observe.sh -l app=my_all -n default -c erlang_cookie | |
# | |
# Don't forget to include `:runtime_tools` in your mix.exs application dependencies. | |
set -e | |
# Trap exit so we can try to kill proxies that has stuck in background | |
function cleanup { | |
echo " - Stopping kubectl proxy." |
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