DEV Community: Steven Stieglitz

Storing Passwords in Sinatra!

Steven Stieglitz — Sun, 28 Feb 2021 19:13:08 +0000

I recently completed my Sinatra project by creating an application which allows a user to create a custom Among Us character as well as view other characters which have been created by the various users on the application.

As part of this project, we were required to create a Users class which can securely login, and therefore, we needed to create a way to store the various users’ passwords securely, as well as authenticate users. This blog will expand further into the following topics:

Storing passwords securely with the Bcrpyt gem and password_digest; and
Has_secure_password and authenticate method.

Storing Passwords

As a software engineer, building applications with secure password protection is incredibly important as users need to be able to trust the applications they use to protect their data. Accordingly, one of the worst things a software engineer can do is store a user’s password as plain text within the application’s database, and that is where hashing algorithms come in handy!

The algorithm will manipulate the data inputted by the user so that it cannot be un-manipulated, and therefore becomes largely inaccessible to hackers and future developers. Additionally, after hashing the password, a “salt” is added, which adds a random string of characters to the hash. Adding the random string of characters to the hash is very important because if the application gets large enough, you run into the inevitability that two users enter the same password for their respective accounts, and by adding a salt to these hashes they will have unique strings despite entering the same password.

Bcrypt

Bcrypt is an open-source gem accessible to software engineers to help with this process. This gem stores a salted and hashed version of the users’ passwords within the database, using a column called “password_digest” (implemented as shown in the code snippet below). The password_digest is used over a simple “password” because this avoids a password from being displayed in plain text and is encrypted prior to being stored in the database. Although this does not completely mitigate a hacker’s ability to access the passwords, it creates another layer of protection against them.

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |u|
      u.string :username
      u.string :password_digest
    end
  end
end

has_secure_password

The ActiveRecord macro “has_secure_password” gives software engineers access to new methods and is called like a normal ruby method, working together with bcrypt to secure passwords without displaying them in plaint text format by tasing and salting them (implemented as shown in the code snippet below).

class User < ActiveRecord::Base

    has_secure_password
end

In addition to salting and hashing plain-text passwords, the has_secure_password method gives the developer the “authenticate” method, which can be used to authenticate passwords. The authenticate method works by taking in a string as an arguments and turning it into a salted and hashed version. It then compares the salted and hashed version with the user’s stored salted and hashed password contained in the database. Should the two versions match, the User instance will be returned, if not, a false will be returned.

I hope I have provided some clarity as to how a Sinatra database stores passwords securely utilizing the b-crypt gem and has_secure_password, for more information on these techniques feel free to visit (https://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html).

Forms and Params!

Steven Stieglitz — Sat, 27 Feb 2021 16:53:34 +0000

During my Sinatra project, wherein I built a project to create a custom Among Us character (a separate blog post is available on this project), I came across the following issues which I will be addressing more thoroughly herein:

Making a form and ensuring requests are structured properly; and
The structure of params.

Making A Form

As for making the form, the attributes of the form allows the software engineer to customize how the request is sent once the user fills in the required fields and hits the submit button. The two most crucial attributes to use when creating a proper form is the action attribute and the method attribute.

Action Attribute

The action attribute defines where the information will be sent. For example, in my application, I give the user the ability to edit their character after it has been created through utilization of a form, with the following code:

<form action="/characters" method="post">
    <label style="color:white;"><i><b>Name</label>
    <input type="text" name="name">

The form action attribute is stating that the URL that the data should be sent to is set to a base of localhost:9393/, then it is followed by characters. This allows for the data to be sent to the general index of all characters.

Method Attribute

With the understanding that the Action Attribute is what allows a software engineer to determine where the date will be sent, the Method Attribute determines how the data will be sent. It is important to note that there are five (5) basic HTTP verb (or methods), which are:

Post;
Get;
Put;
Patch;
Delete.

The most common of these five methods are Get and Post, as the Get method is used to read a resource as opposed to permitting an alteration of any attribute in the database. Conversely, the Post method is generally used to create new resources.

It is important to understand how Get and Post work together, because the Get method, in my project, “gets” the form for the user to input information for the creation or editing of a new character, whereas the Post method will take the information that user “posts” and change the database accordingly.

Therefore, as shown through the above-referenced code snippet, the method is “post” because I am stating that this method should be posting this information to the database, not simply getting or rendering a form for the user to interact with. A get request is shown below:

        get '/characters' do
            require_login
            @characters = Character.all
            erb :'characters/index'
        end

Params

Parameters (often shortened to “params”), which are heavily used in Sinatra Params, are a hash of key/value pairs coming from the browser and encoded in an HTTP request. There are two types of parameters possible in a web application, the first being parameters sent as part of the URL (“query string parameters”). The second type of parameter is referred as a Post data, generally coming from an HTML form which has been filled in by the user and can only be sent as part of an HTTP Post request.

The routes which I primarily used in my application specified a path with a symbol (colon), which alerts Sinatra that any input from the user will be accepted here (see the below code snippet where the :id is being accepted for the parameters of the character's id)

        get '/characters/:id' do
            require_login
            @character = Character.find_by(id: params[:id])
                if @character
                    erb :'characters/show'
                else
                    redirect '/characters'
                end     
        end

Therefore, Sinatra will look for the key for :id and add it to the params hash, setting the string from the URL inputted by the user. Therefore, if the user goes to their localhost followed by "/characters/1", the Sinatra application will return the character with id of 1 (assuming that the user is permitted to view that character).

Another thing you should note is that the controller method defines the route a /characters/:id, which is a dynamic route. This is because the controller action has the :id parameter, which specifies that whenever a Get request is sent to the /characters path with an additional parameter, the parameter should be equal to the id key.

This is crucial for user interaction, because I could have simply rendered the show page of any character I so chose (‘/characters/15 or ‘/characters/3), but it would make for a terrible web application if I, as the software engineer, told the user what character they should be looking at. That is why the dynamic routing is so important, because it allows the user to look at the character that they want to by identifying the id of the character through the params.

I hope I have explained the above information clearly, but for more information please visit (https://webapps-for-beginners.rubymonstas.org/sinatra/params.html).

My Sinatra Application

Steven Stieglitz — Mon, 15 Feb 2021 16:41:01 +0000

My second project requires use of the Sinatra Framework, which I utilized in order to create a customized Among Us character creation app in which the User is prompted to create a custom Among Us character complete with name, age, abilities, and backstory.

The requirements for the project were relatively straightforward, to create two models (one of which is to be selected by the creator, the other being the User model which must be able to signup, login, create, edit, update, and destroy a portion of the first model).

Additionally, the Restful Routing convention was supposed to be used in order to provide a clean template for any future edits to the application, and likely more importantly, setting a structure for any future applications to be built.

My application was focused on the ability of the user to create a personalized Among Us character, and have features in my application that make the user's interaction with the application feel customized.

I was having difficulty distinguishing my user's interface when they were/weren't logged in, so after a bit of research I discovered that utilizing a macro for determining whether a user is logged in or not, I can simply create an "if/else" statement to determine what the user can view, shown as follows:

<% if logged_in? %>
  <div><a href="/">Home</a></div>
  <div><a href="/characters">Characters</a></div>
  <div><a href="/logout">Logout</a></div>
<% else %>
  <div><a href="/">Home</a></div>
  <div><a href="/logout">Login</a></div>
  <div><a href="/signup">Sign Up</a></div>
  </div>
<% end %>

By creating the "logged_in?" shortcut, which ultimately just checked if the User could find their user id within the current session, if the User was found, they would be directed to the Home page to go to either the index if they chose, or alternatively, they could logout.

However, if the logged_in method did not find a current User id within the Session, they would be redirected to the login page with the option to login or go to the signup page.

I used Active Record in order to make my database accessible and make the CRUD operations simple with the pre-defined methods that Active Record provides.

I also started my application with the Corneal gem, created by a previous Flatiron student, in order to make my Model/View/Controller format pre-defined.

Unfortunately, I am not great with CSS or HTML, so I was really learning on the spot to try and incorporate some features and stylistic changes into my application, but I ultimately found that an interactive background showing the website appearing to be in space along with a few color/size changes would have to suffice for the time being (although I will be adding additional features and changing the appearance of this application as time goes by).

Lastly, in order to ensure that a User can only edit and/or delete his/her character, I had to use Validations which also does away with any concerns of URL manipulation (which I originally struggled with).

Other than utilizing the bcrypt gem with a secure password for each user, this application was set up in the above manner and will be improved as I learn how to implement more advanced features.

My First Application

Steven Stieglitz — Mon, 26 Oct 2020 16:59:37 +0000

So this is it, this is the moment that all of the overwhelming pieces of information I have supposedly obtained over the past month will come together, culminating in an “a-ha” moment, and I will have all the knowledge required to build whatever application I so chose. And then I started….

My first attempt was to scrape the Oklahoma City Thunder (my favorite basketball team) website, utilize the information obtained to present the user with a overview of the team roster, and give the user several options for getting more details regarding any player of their choosing.

I created the scraper for the first level, wrote methods for obtaining the information and presenting it to the user in a visually pleasing manner, and was well on my way to creating my application. However, upon creating the scraper for the second layer of the website, for some reason, I could not obtain the information I wanted. I tried every class name I could find, every div, every header, nothing. So, after more hours than I care to admit, I went to my cohort lead and asked him for advice. He told me that he was sorry, but the website I had chosen was inadequate for the project as the javascript was not going to permit me to get the information needed when the attempted scrape took place.

Great, 48 hours down the drain. However, the practice of creating the initial application did give me hope that I would be able to duplicate the process on another website in a fraction of the time. I then found my next idea on metacritic.com, presenting the user with the top 71 Nintendo 64 games sorted by critic reviews. So, I began toiling away, drafting my new scraper with methods to get all of the information I needed to present the user with. Again.

After getting this idea and building a simple scraper, I went to test it out so that I didn’t waste another day on a website that doesn’t work. And then, these words came across my terminal:

“403 Forbidden”.

This was in reference to this line of code:

html = (open(@base_url + "/browse/games/score/metascore/all/n64/filtered"))

Now, I can google all I want, but how in the world am I getting an error on my first line of code? This is the simplest part of the project, and I can’t even get the first line of code to work. I googled for a significant amount of time trying to figure out what this error message was referring to. I had my open-uri gem installed, I had Nokogiri gem as well, so why am I getting this error.

After many failed attempts to rectify this issue, I came across a thread on a Japanese website that suggested I simply change the user-agent. I figured I had tried a million other solutions, why not try one more. So I changed my scraper to this:

html = (open(@base_url + "/browse/games/score/metascore/all/n64/filtered", 'User-Agent' => ‘chrome’))

All of a sudden, everything was working. I did a bit more searching to try to figure out why this would work when all I did was change the User-Agent, but to no avail, and I certainly did not have the luxury of time at this point. So in the future, this is certainly something that I will want to look into further, but for now, it shall be one of the great mysteries of the universe to me (unless a lovely reader of this blog would like to share some insight with me in the comments below).

The next several portions of my code involved scraping the first and second layers of the metacritic website, establishing the has one / has many relationship required in the project (all games have one user review score, but there can be many games within one user review score), and writing some simple language to make the experience more interactive and fun for the user.

However, I then ran across an issue sorting my reviews into separate hashes for the menu so that the user can select whether they want any of the following four options:

    puts "1. View all 71 games"
    puts "2. View games with a user rating of 8 or greater"
    puts "3. View games with a user rating under 8"
    puts "4. Exit”

I had all of the information I wanted, I even pre-wrote the methods for options two and three to pull that information from the arrays I wanted to put the individual reviews in. I just could not figure out how to get the information into those arrays.

Luckily for me, I have a great cohort and spent several hours with several people in the cohort who walked me through the process and eventually led me to this simple code solution:

def self.sort_uscore
    var = @@all.sort_by{|score| [score.number]}.reverse
    var.each do |score|
        if score.number >= 8
            @@all_eight_plus << score
        else
            @@all_under_eight << score
        end
    end

end

All of a sudden everything was working, I had my three arrays (one for all games, one for games with a review score 8 or higher, and one for games with a review score under 8), my methods pulling from them were working perfectly. The only thing left I had for completing my project was to write a few lines for the user interaction, make sure that my app wouldn’t break with the wrong input, and done!

There are a few aspects of this application which I would have liked to have made more intricate, and may even do so moving forward. I would like additional looping features to be introduced for the user, and I would also like to make the styling more intricate, introducing colors and moving features.

However, for now, despite the simplistic nature of my application, it works, its mine, and I am proud to have built it.

From Established Attorney to Clueless Coder

Steven Stieglitz — Sun, 11 Oct 2020 07:16:22 +0000

So there I am, in my office, 7:00 a.m. on a Monday, preparing another Petition to be submitted to the Probate Court to ensure that my clients, and perhaps more importantly my superior, can review my work and make sure every detail is in order. One wrong letter on a form can cause significant commotion and cause a client to lose faith in the firm, potentially costing the firm hundreds of thousands of dollars, and maybe costing me my position.

This has been my previous seven years, ever since I entered law school. The tireless and often thankless work, the hours upon hours of stressing to ensure that everything is always perfect, or at least appears to be to the clients. I often found myself questioning whether this is the path I wanted to be taking, but with every day/month/year that passed, it seemed like changing my course was impracticable. After all, practicality had governed my life, and thus far had served me well. I graduated law school with honors, I got a job straight out of school, and was even elected to the House of Delegates for the State of New York.

On paper, my life was great. How could I ask for more? My career is on track, my fiancé and I share a nice apartment, it seems that everything is in order to set my life’s trajectory for the decades to come. And yet, there was always a nagging feeling that perhaps this was all not quite right. Many of the older and more experienced attorneys would speak about their victories in Court, their many trials and tribulations, how they came to be successful in one of the most mentally straining professions. However, I would see them struggling to keep up with the constant workload, to appease their superiors and clients simultaneously, having to work day and night including most weekends just to keep their head above water.

So I asked myself, is this what I want with my life? If the past seven years are indicative of the next thirty, can I maintain this pace? Do I even want to? Ultimately, my answer was no, but I wasn’t sure how or what to do about it. I have always been fond of electronics and technical aspects of things, I usually was the “non-paid tech guy” of my job, whom the bosses would ask questions about because calling the guy who actually knows how to fix it costs money. But could I do this for a living? Moreover, what aspect of tech would I belong in or could I thrive in?

I have several friends who have delved into the coding profession, one of which graduated from Flatiron several years ago, and he had nothing but positive things to say about the program, and the career choice that he had made. So, when Covid hit, and everyone was forced to basically quarantine their lives, I started doing my due diligence on a potential change from law to coding, to see what options were available, what people were recommending, how those who had made the transition were doing. After weeks of research and consulting several of my friends, I decided it was time to make my move. I let my bosses and colleagues know that I would be leaving the firm in pursuit of a career in coding.

It was potentially the boldest decision I have made with my life thus far, but no risk no reward I suppose. This change could give me what I ultimately sought. The freedom to travel, the liberty to make my decisions for myself, to use my natural logical ability and hopefully be able to exceed at something which genuinely interests me. This was not a decision that should be taken lightly, but nonetheless, it was one I felt was necessary. The legal profession is unfortunately littered with issues that made me feel like it wasn’t right for me. There are certainly less than forthright individuals, there is the constant pressure from clients, from superiors, from opposition counsel. And even those who are successful generally have the same advice for people heading into law school, “don’t”.

I am incredibly thankful for those who made it possible for me to succeed in the legal industry, and there will always be a part of me that wonders what my life would have been like if I maintained the course and continued in the legal profession. However, a far larger part of me is excited for the opportunities that are awaiting me in the coding world. I am not sure where this career will take me, what work I will be doing moving forward, or even where I’ll be living, but I choose to see those question marks as opportunities. These are opportunities for me to grow, opportunities for me to succeed, and as I move forward I intend to seize those opportunities as best as I possibly can.