This blog is part of a continuous series that highlights experiences, insights, and tutorials from learning developers at Flatiron in Web and iOS.
This may not be the most interesting of all stories, but it’s one that needs to be told. That begs to be heard. And here I am, giving this story its very own particular voice (and thick-framed glasses!). So let’s start at the beginning (alas, where most programming stories tend to start), and see if we can’t make it through to the other side. Won’t you, my dear reader, come on this jaunt with me?
We commence our journey in the darkest of crevices, a most important file hidden deep inside the config directory: route.rb. Here we need to establish a root directory, and hatch our grandiose session plans.
We use the resources key word to add seven routes to our web application and quickly narrow these routes down to just the ones we need via the syntax ‘:only’. To keep things clear, for both us and our user, we will name these routes as ‘signup’, ‘logout’, and ‘login’ respectively. We do not play with metaphors here. Literal is best. Now, we have a sessions directory, and we can begin building our sessions conroller. To do this, we type the following into our terminal:
This will give us a controller, and while we’re here, let’s fill out the actions to match our routes:
Here we go!
In order for our sessions hash to function, we need our user to be validated on the home page before visiting any other views. Thus ensues the process of validating and logging in a user. Yet, it is a bit more complicated than that for us programmatically. This involves creating a method we can access from any view on our website. For this we need to go to that forbidden place, we have yet to explore. The application controller.
These two helper methods, current_user and logged_in? will allow us to access data pertaining to our user, regardless of the variables passed in through our controllers. We will be able to access them from anywhere in our views! And do notice the macro ‘before_action :login_required,’ — this makes it mandatory for a user to be logged in before access. But please, let’s not get ahead of ourselves. Before we get to our views, we need to make a pit stop at our post controller to make sure it has access to all the necessary information. Most notably, that we allow a user to visit our home page, or more specifically, posts#index:
This macro does exactly what is says it does (dontcha just love rails?) — it allows only the index page of our posts controller to be visible to a user without first logging in (hence the skip_before_action — get it?!).
So now, finally, we are ready to enter the holy view!!!!
Now one might think, we should go to our post index page. However, that individual would be WRONG. Because we, programmers, are planners. And we want our user to be able to logout no matter what page they are on. I mean, really, sessions wants to be AVAILABLE, people!!! This means that not only are we going to go into that cute little layouts directory, but also we will be rendering a header from the application.html.erb file.
Rendering a partial is super easy, you simply do this within the body of your application.html.erb.
Followed by the creation of “_header.html.erb”
Now, we are embarking on the climax of our tale. The header partial:
This allows the user to logout from every page in our web application, not to mention, a sweet, homey greeting ?.
But we still have one problem. How does our session know who our user is? For this, we will come full circle and revisit our sessions controller.
Like all good tales, there was one quiet character hiding, softly apart from the rest. The user.id. And like a wise old woman, who knows all but is soft spoken, she hid away in the sessions create action. Yet, without this one line of code “session[:user_id] = user.id”, our entire sessions hash would break and fall apart. It’s the link between the two controllers, between our database and our models, and also, the link between our application, and our user.
And that my friends, is how you create sessions in rails. Stalking complete. Story over.
!!!!SPECIAL NOTE YOU MUST READ!!!! Please add the following to your gem file:
This will enable encription of passwords. You will also need to rename the password column in your user’s table schema to “password_digest”. Rails does the rest. Can you say MAGIC?!?!?!!
Now, for reals!
This post originally appeared on Becca Ades’s blog. Read more at A Coder’s Journey.