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.

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.

whois is a command line tool to look up registration information for domains, things like owner, location, and contact info. WHOIS (all caps) is a protocol for querying databases of domain registration (and other related) information. Each domain registrar is required to maintain a database of the domains they register. I use it fairly often when dealing with spammers and or looking at other security issues. However, it has a few rough edges that need to be rounded off.

Speaking of secrets, here’s how I keep them in the shell. Why do I have secrets in the shell? Typically, they are things like API keys and passwords for web services that I use in scripts. For example, I have a script display issues that are assigned to me on the desktop using Geektool. Or scripts to tweet from the command line, when I’m in a command line kind of mood.

Last time, I looked at keeping environment specific configuration using YAML files and Rails.application.config_for. One big issue with this approach is security. It’s very common to have different sets of API keys and API settings for different environments. A simple example is credit card processing. Outside of production you use a sandbox and test cards. Only in production are live API credentials needed.

We need a way to securely handle this information.