NOTE: I wrote this blog post some time ago for Phase 2 of my Flatiron School SE program.
Rubber-ducking doesn't just work for debugging. One of the best ways to learn is to teach others. Doing so can help you solidify your understanding of new/difficult concepts. In fact, there's even a fancy German term for it--Lernen durch Lehren. That's how you know it's legit.
Two new concepts I learned in the Sinatra project phase of my Flatiron course were routing and sessions. Since they were a bit difficult for me to wrap my head around, what better way to make sure I understand them than to teach the nebulous void of the interwebs?
What is Routing?
Routing is basically the method / process by which resources are sent to browser clients in response to HTTP requests. This process can be explained with the request/response cycle.
Let's take my Sinatra Plot Manager app as an example.
First, the user types the url of the resource they want--say... the plot of their sci-fi WIP, "Robots in Space"--into the browser. Next, the browser client builds a request based on that url and addresses it to the correct server (i.e., the server hosting my app).
Requests contain 1) a path that specifies the requested resource and 2) an HTTP verb that indicates what the server should do with the response. In this instance, the verb would be GET--instructing the server to retrieve (or, 'get') the Robots in Space plot resource and send it to the client.
Get it? wink, wink
The router--wherever in the app you've defined routes, like config/routes.rb--processes the request and maps it to the correct controller and action (get '/plots/robots-in-space' in the PlotsController). The action receives the request and passes it to the view, which subsequently renders the embedded ruby (ERB) file as html. Our Plots Controller sends this response back to the browser client and it is displayed as a web page for the user.
My plot manager app requires a user to login to see the resources they've created, such as plots, characters, summaries, etc. How does the server know what resources a client has access to? That's where sessions come in...
Why Use Sessions?
HTTP is stateless, so it's up to the server and client to store their own data about one another from one request to another. Clients use cookies and servers use sessions.
The server sends a cookie when it responds to the client's first request. In my app, that cookie stores the user_id so that each client session has a unique identifier. The server stores a session hash that includes session data, including that user id.
When the client makes requests, the app compares the id in the cookie to the id in the session to make sure the client has access to the resources they're requesting.
A Note on Security
When enabling / configuring sessions within your application, Sinatra gives you the option to set a session secret. According to this article by Martin Fowler, the session secret is "used for signing and/or encrypting cookies set by the application to maintain session state."
The secret makes sure that no one can change the value of their cookies and, for example, sign into your website as an administrator and have access to sensitive information.
This is why it's important to set the session secret securely, according to the guidelines in the Sinatra documentation. Doing so involves--among other things--making sure the secret is a random number with a length of, at least, 32 bytes and storing that secret in an environment variable.
Top comments (0)