Sessions, redirects, and when to set instance variables
If you click on this link, your browser should take you to the Medium home page. You’re not asked to log in again, and you should still see your icon in the top right corner that shows the site knows who you are. Staying logged in from one page to another is an underrated fact of our experience using the web that relies on a few simple operations working together.
When a user logs into a website, the client (your browser) makes a request to the server, which prompts the server to initiate a session. At the end of the day, a session is simply a hash with key-value pairs, including the session ID, which matches the user’s ID and helps identify the user on other pages of the website. Other key-value pairs in the session hash include an expiration date when the session will end, metadata (like whether this particular user is an admin or not), and even login attempts. The session hash is stored in the database until it is cleared, either once the session expires or when the user logs out.
Sessions are a piece of data that a server employs to keep track of a user as they navigate around a website.
All of this keeps the “state” of the user on the server, which is hugely useful for our experience of the web because the language of requests between the client/browser and the server, HTTP, is stateless. HTTP (Hypertext Transfer Protocol) can be summarized as a system of rules that directs how data is exchanged between a browser/client and a server. Each request is independent from any other requests that have already been made or may be made in the future — simply, it does not inherently track what a user has already done without this session hash. The session acts as a kind of name tag (:loginAttempts => 4) and the site can recognize this behavior (“I am the same user that had to attempt my login four times”).
Using sessions to recognize users is essential to the way we use the web. When writing the views for a particular website, controller method variables are often set as instance variables like @user or @users. The application’s controller invokes the methods that define these variables, (in the case of @user, typically relying on the information in the session hash), before rendering a view or redirecting to another view.
There is a key difference between rendering a view and redirecting to a route as it relates to how the @user variable is defined: when a user clicks on a button or types in the URL line, a request is made between the client/browser and the server; when redirecting, a new request is made and that request is routed to a separate controller method. Each request corresponds to a new instance of the controller class, and the brand new controller object must have the same instance variables established for the variables in the view to render correctly. Since we don’t have access to the controller variables after redirecting, errors like “NoMethodError: undefined method ‘[]’ for nil:NilClass” are common in situations like these because the variable @user is not defined in the controller path that led to that new view. Rendering a page like ‘edit’ can work as intended because @user is defined in the controller, but redirecting to the same page might not if @user is not defined in the controller.
