An update to my somewhat popular How I Start Rails Projects post. As before, I start with:

1
2
3
4
5
6
rvm use 2.4.1@project-name --create
gem install rails
rails new project-name
cd project-name
rvm use 2.4.1@project-name --ruby-version
echo '/.ruby-*' >> .gitignore

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.

OK, you’re in a situation when you can’t use cookies, specifically you’re in an iframe and Safari will only accept a cookie in an iframe if the browser has already visited the site outside of the iframe. Without cookies, there are no sessions. The simple work around is to force the user to visit the site directly, but that’s often not an option. What’s Plan B?

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.

Sessions depend on cookies, and you can’t always use cookies. When can’t you use cookies? Safari in an iframe for one. I do a lot of integration work, add ons for various platforms, and typically you add on is embedded via iframes.

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:

1
cap production ssh

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.