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.
I looked at keeping environment specific configuration using YAML
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.
Previously, I looked at the simply way of creating Rails stages that
shared same configuration with Production by simply importing
production.rb into the new stage:
This is a good start, however it makes a bad idea, stage conditional code, worse:
A quick tip — When I’m deploying Rails apps to Staging or Beta I try to keep the configuration as close to Production as possible. I’ve gotten bitten one too many times by things that only break in production due to configuration (assets for example).
The simple way to avoid this issue is to use the exact same configuration for those extra environment, but there’s a wrong way and a right way.