- Sessions
- Has_secure_password
- Params
Sessions
First, we should start explaining what sessions are. Sessions are a method that behave as a hash. That means that it is a way to keep some data in memory for the server.
Second, you might ask why we use them? Fear not, you only have to look below!
When your app keeps running on the internet, it will receive multiple HTTP requests from other computers. This means too many users that can log in and send data!
This is a problem…. The Sinatra part of an app doesn’t care who sends the request. The way it works is that it gets the request, it sends it to the right route, and then it sends back the right response to the client (browser).
But what happens when you are no longer logged in? How do we keep this information?
By keeping the sessions object!
Now let’s go over how this is done. You begin by enabling sessions in your application controller. Here is an example below:
Then, create the sessions object. Sessions stay in the browser as part of a cookie. (Let’s hope you have an understanding of what a cookie is.) Sessions give the server a way of tracking specific data and remembering it for each user.
Let’s get through an example:
This piece of code is a Post request that is looking for a trainer with the username param and assigning it to the variable of user. If Ruby will return “truthy” for the existence of the found user AND also the “truthiness” of the submitted password param, validated with authenticate, then we will assign the user ID to the session. Then this redirects the user to the welcome page. Otherwise it will return nil “falsey” and redirect user to a failure view.
Has_secure_password
Want to protect your users password? Well, look no further!
When building a web application using Sinatra or Ruby on Rails that authenticates users for sign up, log in, and log out. This has_secure_password method becomes very useful.
We are not storing the password in the database directly as a password, we are storing it in the password-digest, an attribute that is required in our database to store each authenticated password users have made. The has_secure_password works with the Bcrypt gem, which has a secure hashing function. It accepts a password, transforms it into a password_digest and then stores it to the password-digest in the database. In other words, the users password gets stored as a long encrypted string.
When the user is logging back in, the has_secure_password will collect the password that was given and converts it to the encrypted string with the Bcrypt gem and checks to see if it matches in the password_digest. If it does.. you guessed it, the user will be logged in!
Params
Short for parameters, params are important because we cannot build a web application without understanding them .
Params comes from the ActionController::Base which is accessed by your application through the ApplicationController. Params are the parameters being passed to the controller through a GET or POST request.
Params act very similar to a hash, they contain keys and values. So we can access to its data in different ways. One of them is to access to params through forms.
More about forms …
- Forms are important because we fill out online forms everyday. Some examples of forms are sign ups, logins, registrations forms and so on.
- Forms are the most common way for users to pass data to a web application.
How do we connect forms to a Sinatra Application?
We connect HTML forms to a Sinatra Application by using forms. These forms take attributes like user’s name or email, for example. Then, this returns an interpolated string. Here is an example below:
This form above is part of my “Sign up” form from my Sinatra Application. Here we are telling our form where and how to send the data from the user. In other words, with the action attribute we are telling the form what route the POST request should be sent to. In this example, we are posting to a route called /signup. The method attribute tells the form the kind of request that should be sent to the server after the user clicks the submit button. But why a POST request? The answer is simple. In general, forms user POST request in order to “post” data to the server.
After the request, the Sinatra server receives the string, and it parses to get the data as a hash with its keys and values pairs. These key/value pairs are accessible from the params hash. Following our example, our hash would look like this:
{"username" => "McLovin",
"email" => "McLovin@mail.com"
}Let’s keep breaking down the form! The next lines refer to <input>. This field must define a “name” attribute that defines how our application will identify each <input> data. Input names will need a username, email, and password.
We also should have clear about the corresponding route every form needs. Then, checking out our controller file, and still following our previous example, we see this:
Well, we have a POST route that it matches the method attribute.
To sum up, whenever the user submits the form, it will be possible to access the data entered into this: params[“username”]. We will be passing the data in the form of a hash where the key will be the name of the data (name=”username”) and the value will be whatever the user enters.
Routing Parameters
This matches the path of your URL.
Params matches the string that you set your dynamic name to be. It is the string after the colon marks(:). This will add the key to your params hash and set it to the string.
Ex: ‘/pokemons/:id’
In return, you will receive dynamic data back.
Ex: ‘/pokemons/1’
This will set the params of pokemons to be the id of 1.
SIDE NOTE — If you ever need to see what the info in your params hash looks like, just create some string-interpolated text in your post '/users' route and then check your browser.
This is valuable knowledge, if you can pop your params into a string to see the contents of params in your browser, you can do anything you want with params!
