An update to my somewhat popular How I Start Rails Projects post. As before, I start with:
1 2 3 4 5 6
The only change is bumping Ruby to 2.4.1.
But this leads to a rant:
Ever put your Mac to sleep only to come back find it’s still awake? This happens because something is telling the power management subsystem it can’t sleep yet.
A quick one today — creating S3 Static Website Hosting redirects with the AWS CLI. Clients often want to have www.example.com redirect to example.com or vice versa. Why? Because SEO. I suspect “SEO” is smart enough recognize one site with two URLs, but hey, I just work here.
It’s easy enough to do this sort of thing in Apache or NGINX. However, if the real site is in AWS, especially CloudFront, I like the simplicity and single purposeness of using S3 Static Website hosting to for redirects.
So, I’ve looked at the utility and security of cookies and I’ve at looked the utility and security of sessions. It you’ve been following along, then you know that sessions are great, they provide a secure way to verify who you are talking to.
Sessions are great. Great that is — until you can’t use them.
A quickie this time. I use Capistrano to deploy my Rails apps. There was a gem for Capistrano 2 that added an ssh command as in:
This would open an SSH connection to the production server and cd you to the current directory for the app. Super handy if you work on a lot of projects and don’t want remember what the server names and deploy paths for all of them.
The Capistrano 3 has a much different internal structure and the gem is long abandoned. Fortunately, it’s easy to recreate this functionality in a view lines of code.
Last time I took a reasonably deep dive in cookies. Cookies can keep state information and setting for visitors to a site. However, by default they aren’t secure, being sent in the clear and easily modified. You can turn on security option, but an even easier is stepping up to sessions.
“Sessions” are a common concept across web development platforms, but interestingly, they are actually a standard like, say, cookies.
I’ve been working on a post about using JWTs JSON Web Token (JWT) when you can’t use HTTP cookies for sessions. As I dug into it, I came to realize that understanding the risks of using JWTs requires a bit of understanding about how HTTP cookies (and session) work. So, here’s a primer.
A quickie this week. When I’m wearing my Ops Hat (I totally need to make me an “Ops Hat”, something with lights and a grappling hook), I often find myself setting up servers for other people. That requires getting them SSH access to the server and that requires getting their SSH public keys.
There are lots of excellent solutions out there for managing public keys within an organization, but these servers are one-offs, so that infrastructure isn’t going to get built.
The good news is that 9 out 10 times the people in question have GitHub accounts, and if someone has a GitHub account, they likely have a public SSH public key.
JSON Web Token (JWT) have come in to my life. I like them and you will too… Pronounced “jot”, the short version is that they are cryptographically signed blobs of JSON. They pass data around that can be viewed, but not tampered with.