DEV Community: bfirestone23

Ruby on Rails + OmniAuth + Devise: Implementing Custom User Attributes

bfirestone23 — Mon, 15 Mar 2021 21:53:56 +0000

When starting my first Ruby on Rails application, I knew one thing for certain: instead writing line after line of code to manage user sign up, sessions and authentication, I wanted to take advantage of a great Ruby gem called Devise. For the uninitiated, Devise is billed as a "flexible authentication solution", but that's quite an understatement in my opinion. You can check out everything it does here, but to put it simply, Devise handles everything from user registrations, to sessions, to forgotten passwords and everything in between.

Using Devise relieves you of a lot of work and potential headaches and/or bugs. However, if want your User model to have any attributes other than email and password, adjustments will need to be made. Luckily, this is as simple as adding those custom fields to Devise's pre-built forms! Easy enough.

Devise is a powerful tool on its own, but the project requirements for my app also called for the use of OmniAuth to allow users to sign in or sign up through a third-party like Facebook, Google, or GitHub (I ended up going with Facebook using the OmniAuth-Facebook gem. This is where that hurdle of implementing your additional model attributes into this sign-up flow will be a bit more tricky.

As an example of the issue at hand, let's say I'm building a job finder Rails app. I have three models: Users, Jobs, and Applications. Users can either sign up as an employer or an applicant (I created an 'employer' attribute with a boolean value) - only employers can post jobs, and only applicants can apply to them. With the standard OmniAuth implementation, a user will click a link to direct them to the third-party sign-in form, and once they sign in, they'll be redirected back to our server in order to create a User instance. What we need to do is get some data from the user before they click that "Sign In with Facebook" link, store that data somewhere, and pass it back to our model upon the User instance being created. So let's get to it!

NOTE: We are only setting up this user flow for a new registration/sign up, not a new session/log in. This is because a user should only have to specify what type of user they are once - not every time they visit the site.

Step #1 is building out a route and corresponding view and controller action to get that sweet sweet data from our user. In our example, we simply want them to select between signing up as an employer or applicant. Here's our route for that page - use whatever naming convention you prefer as these routes won't exactly be following RESTful conventions.

devise_scope :user do
    get '/confirm', to: 'users/omniauth_callbacks#landing', as: 'get_landing'
end

Note that this route will be nested in the :user devise_scope because we are utilizing Devise in our application. Now that we have our route, let's establish our controller action:

def landing
   render 'devise/registrations/landing'
end

That was easy! Ok, onto our form - for this example, we just need a couple radio buttons and a submit button, plus a POST route and controller action to send the data we receive back to our model. There are a few ways to get this done (and mine probably isn't the best!), but here's my form code (including some bonus Bootstrap styling):

<%= form_with url: sending_path do |f| %>
    <%= f.label :employer, class: "form-check-label" %>
    <%= radio_button_tag :employer, 1, class: "form-check-input" %>
    <%= f.label :employer, "Applicant", class: "form-check-label" %>
    <%= radio_button_tag :employer, 0, class: "form-check-input" %>
    <br><br>
    <%= f.submit "Submit", class: "btn btn-outline-primary" %>
<% end %>

And here's the sending_path route that is being used as that form's URL (placed in the same block under devise_scope :user as the previous route):

post '/confirm', to: 'users/omniauth_callbacks#add_to_session', as: 'sending'

Ok, now we're cooking! This is where the rubber meets the road - we're going to save that user-provided data into the user's session (a great place to store small amounts of data needed through multiple requests!). Since my employer attribute is a boolean, I'm going to stick with 1's and 0's. As you can see in the form above, selecting 'employer' will set a value of 1, and selecting 'applicant' will set a value of 0. Here's how we move that data into our sessions hash in the controller:

def add_to_session
   if params[:employer] == "1"
      session[:employer] = 1
   else
      session[:employer] = 0
   end
   redirect_to staging_path
end

Super simple, right? Now we have access to the user's selection in the session[:employer] hash from any controller. That last line of code is redirecting the user to a landing page which finally has the 'Sign In with Facebook' button we've been waiting for (for Facebook Oauth, it's taking the user to /users/auth/facebook). We're almost there - but if we click that link now it will send the user through the standard Oauth sign-up flow, and we need to first make some adjustments so that our user is created with their user-type selection in mind.

First, let's add some logic to the #facebook controller action (the action created when first implementing Oauth) to parse our session[:employer] hash into a boolean value that our model will be able to read and assign to the employer attribute.

employer = false
if session[:employer] == 1
   employer = true
end

Next, we'll update the .from_omniauth method (this should've been set-up when first implementing OmniAuth!). My solution was to add a second argument to this class method - in my case, the 'employer' variable which houses that boolean value. Once inside that method, set the user's employer attribute equal to that variable you just passed in, and boom - your user who logged in via Facebook now has a designated user type.

NOTE: If you have OmniAuth set up to not only create but update a user upon signing in, you'll want to use the fancy ||= operator when setting the user's employer value. This is so that when a returning user signs back in using Oauth, the existing value of their employer attribute is used instead of a new (and likely nil) value.

The final .from_omniauth method should look something like this, more or less:

def self.from_omniauth(auth, employer)
   user = find_or_initialize_by(provider: auth.provider, uid: auth.uid)
   user.email = auth.info.email
   user.password = Devise.friendly_token[0, 20]
   user.name = auth.info.name
   user.employer ||= employer
   user.image = auth.info.image
   user.save
   user
end

And there you have it. Now, not only do you have a modern sign-up/log-in system, but it's customized to your liking. As I was working through this process I wasn't able to find any blogs documenting how to go about this, so if you encountered the same problem, I hope this helped!

The Understated Power of ERB (Embedded Ruby)

bfirestone23 — Fri, 12 Feb 2021 18:10:53 +0000

Any software engineer will tell you that it's imperative to know how to "mix-and-match" various technologies, programming languages, and/or frameworks in order to design and build a sound final product. For example, we typically use HTML to build the structure and content of a web page, CSS to add styling and formatting, and Javascript to add certain functionality and dynamics. While this trifecta may be the front-end standard, there's an unsung hero at your disposal (if you code in Ruby) - ERB, or Embedded Ruby.

An ERB file allows you to embed Ruby directly into HTML, providing a convenient and practical way to render dynamic content on a web page.

Let's say you're creating a simple web application and want to greet the user when they log in. Simple HTML won't work, because it's not dynamic! So how do you render the current user's username on the page? With ERB, it's incredibly intuitive.

Assuming that @user, an instance variable made available to us via the current route in our controller, is equal to the current user object, it's as simple as:

<p>Welcome <%= @user.username %>!</p>

Here we are embedding the user's username attribute directly into the <p> element in our HTML by using the following opening and closing tags around our Ruby code, also known as "expression tags": <%= some ruby code %>. Expression tags will run and display the return value of your code. Pretty cool, right?

Well, it gets better. We can also use what are called "execution tags" to run code without rendering! This is where the power of ERB really shines. For instance, referring back to our welcome message example - you would only want to render that message if the user was signed in, right?

For this example, let's also assume that we have access to a '#logged_in' helper method, which returns the status of the user's session:

<% if @user.logged_in? %> 
  <p>Welcome <%= @user.username %>!</p> 
<% end %>

Note how the conditional if statement is wrapped with a <% tag on each end - these are execution tags! They won't render the code between them to the front-end, instead they'll just run that code on the indicated snippet of HTML. In this case, the "welcome" message will only render if @user.logged_in? returns true.

Even with just this one simple example, you can already see how powerful and versatile ERB can be - you could essentially write all of your Ruby code in ERB if you wanted to (but, separation of concerns, right?).

I used a ton of ERB in my most recent project, a CRUD, MVC Sinatra web application which allows users to create and share movie reviews (available via Heroku). Here are a few slightly more complex examples of how ERB can be used to dynamically render HTML.

Iterating through an array of objects and rendering table data for each:

<% Movie.all.each do |movie| %>
  <tr>
    <td><a href="/movies/<%= movie.slug %>"><%= movie.title %></a></td>
    <td><%= movie.director %></td>
    <td><%= movie.genre %></td>
    <td><%= movie.release_date.strftime("%-m/%-d/%Y") %></td>
  </tr>
<% end %>

Rendering a link in a nav bar based on the current URL:

<% unless @request.env["PATH_INFO"].include?("welcome") %>
  <a href="/welcome/<%= current_user.slug %>"><button type="submit">Home</button></a>
<% end %>

Or dynamically setting the value of an input element:

<input id="director" name="director" value="<%= @movie.director %>"><br>

In summary, ERB is a key technology for full-stack Rubyists and should not be overlooked. Whether you leverage it just to add some simple logic to your web page, or to create a layout template (<%= yield %>, anyone?), it is an undeniably powerful tool. This blog only scratched the surface, so be sure to dig into the documentation! Rubyapi.org provides a good starting point.

What I Learned Building My First App

bfirestone23 — Mon, 11 Jan 2021 21:04:24 +0000

I've just completed my first app build, and even though it's been a few days since writing my last line of code, there's already been a flood of ideas for how to improve, iterate, and evolve its functionality. In fact, it's an almost annoying barrage of ideas (that may or may not actually be good) - it'll stop eventually, right?

My first app is the PHL Covid Testing Ruby gem. It uses OpenDataPhilly's testing location API and allows the user to search for a nearby testing site in Philadelphia, PA (by name, zip code, drive-thru, or walk-up) and then view full details for a selected location. While I created this app to flex my object oriented Ruby muscles, I also wanted its functionality to be meaningful and truly useful in the user's day-to-day life.

The biggest thing I learned about development in the process is this:

"Focus on the step that is in front of you, not the whole staircase".

Not only does this apply to something like setting up your environment before diving into writing code, but it also applies to learning to code as a whole!

When first starting my app build, like many, I felt lost and had little confidence in the code I was writing. At every turn I was looking back through lessons I had completed for refreshers on concepts, reading through far too many StackOverflow posts, and wasting time watching YouTube tutorials that attempted to boil a million concepts down to a 30 minute video. Feeling frustrated, I put my trust in the quote above, and stubbed out the basics - starting with creating classes and identifying their responsibilities, then establishing the necessary has-many and belongs-to relationships, I began to feel the momentum building and giving me a clearer and clearer picture of what steps I needed to take next.

That momentum is what I've come to recognize as a true sign of progress in my coding journey. If you would have asked me a month ago if I could've built a Ruby Gem from scratch, of course I would've asked, "what's a Ruby Gem?" - but the cumulative result of consistent incremental change is truly a force to be reckoned with. If I hadn't spent months laying a foundation of fundamental coding practices and concepts, I would've completely fallen flat trying to create my own (extremely simple) CLI app. If I hadn't started development by stubbing out the core structure of my code, I wouldn't have been able to see the path to the finish line so clearly. Looking to the future, without building my first CLI, I wouldn't be able to build by first web app.

In short, while it may sometimes be hard to see the big picture in the midst of uncertainty - put your trust in baby steps.

Why I Decided to Learn Software Engineering

bfirestone23 — Mon, 21 Dec 2020 20:37:01 +0000

My professional journey has never been easy for me to suss out. Muzzled by indecision in my late teens and early twenties, like many, I had no clue what I wanted to do "when I grew up". My only true passion in life has always been music - playing it, listening to it, seeing it performed live - it has always been at the center of my life. At the same time, as a self-proclaimed "optimistic realist", the knowledge that sustaining myself purely on my passion for music wouldn't be easy or necessarily worthwhile has always been at front of mind when thinking about my career. I thought of all the "starving artists" of the world, or all of the underpaid & overworked staff that make live music events happen, or genius musicians playing to empty open mics every night, and on and on. It's a hard truth to swallow, but for me, a necessary one.

For some, coming to this realization can be really tough. You might ask yourself, "how can I ever truly enjoy my career if it doesn't align with my biggest personal interest?" - and for a while, this question was running through in my mind from morning until night. I worked in various aspects of the music industry from 2014 until late 2020, and while I don't regret a minute, I needed those six years of experience in order to come to the decision that changed my career trajectory and put everything into focus - to dive head-first into software engineering with the same passion and drive that I applied the first time I picked up a guitar.

Truthfully, studying software engineering never seemed attainable to me. I've been obsessed with technology for as long as I can remember - I vividly remember geeking out when our family first got a desktop PC in the early 2000s and the possibilities were seemingly endless, even with just a dial-up connection. Since then, I've had a burning curiosity of how 0's and 1's make up the digital world, but always just thought, "I'm probably not smart enough to understand it". This summer, with some extra free-time on my hands due to the pandemic, I decided to finally test that hypothesis and pick up HTML, CSS, and a bit of Python - and I quickly realized how wrong I had been all these years.

With just a few weeks of exposure to programming, I began seeing the similarities between it and music. At their most basic levels, both operate within a provided framework (music has scales, programming has languages) but how the creator gets "the job" done, such writing a song or developing an app, is largely up to them - they have the agency to impose their vision and creativity on the project to make it their own. With this, I realized that this type of agency is really what I've always been looking for in a career, and it's not exclusive to music or art after all.

With this epiphany fresh in my mind, I decided that it was finally time to do the thing I had always told myself I could never do. I quit my 9-5 job at a major record company in November 2020 to spend the next 6+ months studying programming in pursuit of my dream of being a software engineer - to have that agency I've always wanted, to be able to flex my creative muscles in new and exciting ways, and to hopefully make the digital world a better place while doing it.