Wrapping up my Flatiron Rails Project over here and wondering, what did I find *helpful* in this challenge? 💡 Aah yes, those helper methods really came in handy and *helped* me clean up my code! If I had time, I would add a lot more of them, but for now, we’ll just talk about some basic helper methods that can tighten up the job of preventing users from willy-nilly accessing someone else’s account information.
I used three helper methods for this: #current_user, #logged_in and #require_login.
As you can see, these are very simple and concise methods. This is great, it helps us keep a separation of concerns, so that our code is clear and dynamic.
The first method, current_user helps us define — you guessed it — a current user. What does that mean in coding language? It means we need to identify a key of some sort that the current browser session can use to communicate with the database and persist information through a browser’s request/response cycle. In order to do this we need to access the session’s “hash” to assign a user_id, thus providing a link between the user and their current session, until the user logs out or their session expires.
Dispatcher.find_by(id: session[:user_id] is used in conjunction with our SessionsController #create method, which assigns the session[:user_id] to equal the id associated with the user if we find that user by username in the database and they authenticate their account with the correct password.
After we make sure the username exists and assign it to the session[:user_id], we then use the current_user method to continuously check throughout the application that the session[:user_id] that links the user to the browser session is still the right id. I like the analogy given in our lecture regarding cookies, as it applies similarly here. It’s like going to a club and they verify that you are old enough to enter and give you a wristband, so you don’t have to keep showing them your…id. The bouncer is kind of like the helper method, it keeps looking for your id to make sure you are authorized to see the data you are requesting.
Not only can we use helper methods for verification/protection, but also just to help us grab data from the database or accomplish any other defined task that we give it. In this case, I’m using the current_user method and chaining ActiveRecord methods onto it to access the relationship between a single dispatcher (or user) and their respective callers on the hotline. The whole line of code without the helper below would be as follows: @callers = Dispatcher.find_by(id: session[:user_id]).callers.uniq
This is all to explain a few helper methods for user authentication, but as you can imagine, this concept could be used in many ways. It basically allows us to single out repetitive code and chip it down, so that instead of rewriting the same 10 lines of code over and over again, we can just write three, or five, etc and then reference one line of code throughout our application to invoke that chunk of code.
As you can see at the top of the ApplicationController, once we create the helper methods, we then have to include them in the rest of our application by calling helper_method :method_name. And from here we can either call them individually in specific places, or use a callback like before_action to tell the application when to invoke that particular helper method. In this example, we are calling require_login before every action, unless specified elsewhere, such as in our SessionsController where we need to let the user login to their session before we start asking them if they are logged in!
These three methods can all be used in different ways to verify that the user is the right user, that the user is logged in and if they aren’t to redirect them to the homepage, so that they can’t see any information without securely being logged in. Below you will see how we can use current_user to protect the user’s data from being changed unless they are verified through the current_user helper method and their id matches the session[:id]
Okay, well hopefully this is helpful in clearing up the flow of a helper method and how they can be useful. They aren’t called until they are called, so they aren’t active until they are needed. That may seem obvious, but sometimes we have to state it to make it fully understood, like talking to a rubber ducky ;)