A Brief Intro To Cookies
In your humble journey on the path of being a web dev, you’ll likely get to the point of wanting to store some basic information about your user — their user ID, their site preferences, their shopping cart, or maybe simply whether or not they’re currently logged in. Authentication can be a deep subject. In the world of Ruby on Rails (which is how I’ll be talking about this information), the go-to solution often seems to be Devise — a so called “one stop shop” for user authentication. However, if you take a quick look at the documentation for Devise, you’ll find a section of its ReadMe titled “Starting with Rails?”, with not much more to say than the following: “If you are building your first Rails application, we recommend you do not use Devise.”
Luckily, Rails provides a couple of ways to dive into authentication at an effective surface level.
A bit of background
Cookies have existed as a solution to those previous problems for almost as long as the internet was popular. It’s likely that you’ve heard of and previously come across cookies if you’ve had any basic experience with browsing the internet. Maybe you’ve run into computer problems, and your IT person suggested trying and clearing your cookies. But oh no! You did that, and now you’ve lost a bunch of info you’ve saved on your favorite websites. This might give you a clue as to what cookies are doing — storing some info on your local environment for later retrieval by a website or server.
Let’s dig just a little bit deeper. There’s probably been a lot of misinformation about cookies for just as long as they first started being implemented. The reality of what they are and what they do might be a bit simpler than what you’re expecting. Cookies are just text files, containing a series of key-value pairs. User ID: 971375. That’s mostly it. They get sent from a web server to a client for temporary storage, to be read back to the web server later. They might have an expiration date associated with them, or it’s likely that they will be disposed of when you close your browser.
It is true that cookies can go a little bit further. One might be skeptical of third-party cookies unrelated to the base website you might be viewing. These may be tracking more in-depth, personal information about you — -perhaps info you’ve input into the website about your location, age, interests, even credit card information. Or beyond that, maybe they’ll utilize cross-site profiling to (probably unwittingly to you) track your movement across multiple sites, helping the cookie administrator to create a more complete profile of you with which they can then use to advertise to you or sell your data. Fun! I won’t even get into the topics of super cookies (designed for permanent storage) or zombie cookies (they can be recreated after deletion).
Luckily, as we’ve seen, cookies can be cleared. They can also be managed, blocked, and as we’ll find out, viewed and inspected. As we’ve also seen, you probably want some cookies, so it probably doesn’t make sense to block cookies wholesale.
It’s safe to say that cookies may not be the perfect solution to every situation. One reason is that, due to their implementation, a cookie gets associated with your specific browser. It will not track across browsers or machines, nor will it keep track of multiple users on the same browser or machine. It’s also possible for them to be read by intermediaries, such as a wifi hotspot.
But you’re a trustworthy website administrator, ready to use cookies for good, and you probably don’t need to get super concerned with anything beyond basic security for right now. So let’s jump in.
My Very First Rails Cookies
This is actually gonna end up being pretty simple. Let’s start a new Rails app, and then create a controller that looks something like this:
class CookiesController < ApplicationController def index cookies[:hello] = "Hello world!" endend
Remember when I said that a cookie is nothing more than a key-value pair? Does that sound familiar? As it turns out, in Rails, you have access to a hash-like object, called cookies, via ActionDispatch::Cookies. If we were to go into the console and inspect cookies, we would get a mess of information back that would be hard to parse. If we call cookies.class, we’ll get back “ActionDispatch::Cookies::CookieJar”. Again, not quite a hash, but Rails lets us treat it like it is. Call cookies[:hello], and we’ll get back “Hello world!”
Let’s get out of the console and quickly throw together a corresponding route, as well as a view containing anything you want. Now start your server and view your index page. I use Firefox, so if you’re like me, you can hit the hamburger bar, open Web Developer, then Storage Inspector to find your cookies. In Chrome, it should be Developer Tools, Application, Cookies.
On our test page, there should only be a few cookies. Hopefully, you’ll find “hello”, with the value of “Hello+world%21”.
Sessions
Rails also provides support for sessions to keep track of client state. You might want to be able to create a new session when a user logs in, read some info about that session, and then destroy the session when the user logs out. Again, not so painful to do in a basic way — these actions can be managed from a controller, with separate actions for creating, reading, and destroying to be called at the appropriate times. Our session will also be handled via ActionDispatch and treated like a hash. The session will end when your user exists his or her browser, or when the session times out. In addition, a session can also be handled or stored via ActiveRecord.
You might want to use a session if you want your information to be stored on your server rather than by the client, or if you simply want to utilize more data than a cookie provides.