DEV Community: Thierry Chau

How to Use Sqids in Rails to Obfuscate IDs

Thierry Chau — Sat, 24 Aug 2024 15:17:15 +0000

When developing web applications, it’s common to expose database IDs in URLs, such as example.com/posts/123. While this is convenient, it has potential drawbacks. Sequential IDs can reveal information about your database, like the number of records or the order in which they were created. To address this, developers often look for ways to obfuscate these IDs while keeping them reversible for internal use. This is where SQIDs come into play.

What is Sqids?

Sqids is a library designed to generate short, non-sequential, and URL-friendly IDs from integers. Unlike UUIDs, which are long and not user-friendly, Sqids provide a compact alternative that can be used in URLs to hide the real database IDs. They’re particularly useful in scenarios where you want to obfuscate your IDs without modifying your database schema or introducing significant overhead.

Why Not Use UUID?

UUIDs (Universally Unique Identifiers) are often used as an alternative to numeric IDs for their uniqueness across distributed systems. However, UUIDs have a few drawbacks:

Length: UUIDs are typically 36 characters long, which can make URLs cumbersome.
Not Sequential: While they are unique, UUIDs are not sequential, making indexing in databases less efficient.

On the other hand, Sqids offer a balance between security, URL friendliness, and reversibility, making them an ideal choice for many applications.

Implementing Sqids in Rails

Here’s how you can implement Sqids in a Rails application using a concern. This approach ensures that you don’t have to modify your database schema, and you can easily integrate it with your existing models.

Step 1: Install the Sqids Gem

First, add the Sqids Ruby gem to your Gemfile:

gem 'sqids'

Run bundle install to install the gem.

Step 2: Create a Concern for Sqids

Next, create a concern to encapsulate the logic for encoding and decoding Sqids:

# app/models/concerns/sqids_encodable.rb

module SqidsEncodable
  extend ActiveSupport::Concern

  # arguments here are optional ; you can change the alphabet to change the encoding sequence
  SQIDS = Sqids.new(alphabet: 'k3G7QAe51FCsPW92uEOyq4Bg6Sp8YzVTmnU0liwDdHXLajZrfxNhobJIRcMvKt', min_length: 8)

  def to_param
    sqid
  end

  def sqid
    SQIDS.encode([id])
  end

  class_methods do
    def find_by_sqid(sqid)
      find(SQIDS.decode(sqid).first)
    end
  end
end

This concern does a few key things:

to_param method: Overrides the default to_param method to return the SQID instead of the numeric ID. This ensures that Rails uses the SQID in URLs.
sqid method: Encodes the model’s ID using Sqids.
find_by_sqid method: Allows you to find a record by its SQID, decoding it back to the original ID.

Step 3: Use the Concern in Your Models

To use this in a model, include the SqidsEncodable concern:

# app/models/post.rb

class Post < ApplicationRecord
  include SqidsEncodable

  # Your model logic here
end

With this setup, whenever you generate a URL for a Post, Rails will automatically use the SQID instead of the numeric ID.

Step 4: Use Sqids in Your Controllers

When querying for a record, use find_by_sqid:

# app/controllers/posts_controller.rb

class PostsController < ApplicationController
  def set_post
    @post = Post.find_by_sqid(params[:id])
  end

  # Other controller actions
end

This ensures that Rails can correctly retrieve the record using the obfuscated ID.

Conclusion

We went from example.com/posts/123 to something like example.com/posts/5sQ1BZoD.

Sqids offer a practical solution for obfuscating database IDs in a Rails application. They allow you to hide the actual IDs from users, while still being able to reverse the process internally. Compared to UUIDs, SQIDs provide a more user-friendly, compact, and efficient approach.

It’s important to note that while Sqids obfuscate the IDs, they do not encrypt them. If you require encryption for your IDs, you’ll need to look into more robust security measures. However, for most applications, SQIDs strike a good balance between security and usability.

Learn more about Insecure Direct Object Reference
Learn more about Sqids | GitHub repository

Understanding Fall-Through in Java Switch-Case Statements

Thierry Chau — Wed, 17 Jul 2024 15:26:05 +0000

In Java programming, the switch-case statement is a control structure used to execute one block of code among many based on the value of a variable. It can be more efficient and readable than using multiple if-else statements. One important concept to understand when working with switch-case statements is "fall-through."

What is Fall-Through?

Fall-through occurs when the code execution continues from one case to the next without encountering a break statement. By default, after a matching case block is executed, the control flow will fall through to the subsequent case blocks until a break statement is encountered or the switch statement ends.

Syntax of a Switch-Case Statement

Here is the basic syntax of a switch-case statement in Java:

switch (expression) {
    case value1:
        // code block
        break;
    case value2:
        // code block
        break;
    default:
        // default code block
}

Example of Fall-Through

Let's look at an example to understand how fall-through works:

int day = 2;
switch (day) {
    case 1:
        System.out.println("Monday");
    case 2:
        System.out.println("Tuesday");
    case 3:
        System.out.println("Wednesday");
    default:
        System.out.println("Other day");
}

In this example, the output will be:

Tuesday
Wednesday
Other day

Explanation

When day is equal to 2, the case 2 block is executed, printing "Tuesday." Since there is no break statement after case 2, the execution continues to case 3 and then to the default case, printing "Wednesday" and "Other day" respectively. This is a classic example of fall-through behavior.

Preventing Fall-Through

To prevent fall-through, you should end each case with a break statement:

int day = 2;
switch (day) {
    case 1:
        System.out.println("Monday");
        break;
    case 2:
        System.out.println("Tuesday");
        break;
    case 3:
        System.out.println("Wednesday");
        break;
    default:
        System.out.println("Other day");
        break;
}

Now, the output will be:

Tuesday

Intentional Fall-Through

Sometimes, fall-through can be used intentionally to execute multiple cases with the same block of code:

int day = 2;
switch (day) {
    case 1:
    case 2:
    case 3:
    case 4:
    case 5:
        System.out.println("It's a weekday");
        break;
    case 6:
    case 7:
        System.out.println("It's a weekend");
        break;
    default:
        System.out.println("Invalid day");
}

In this example, day values 1 through 5 will all result in "It's a weekday" being printed.

Conclusion

Understanding fall-through in switch-case statements is crucial for writing clear and bug-free Java code. While fall-through can be useful in certain scenarios, it is generally a good practice to use break statements to prevent unintended behavior.

Note: Unlike Java, the case-when construct in Ruby does not exhibit fall-through behavior. Each when clause is independent, and execution does not automatically continue to subsequent when clauses without explicit instructions.

Learning to learn

Thierry Chau — Thu, 05 Oct 2023 05:15:14 +0000

It's been a bit over a week since I've started the Software Development Foundation training with Discovery Partners Institute in Chicago. And I've learned a lot.

One main thought that keeps coming to my mind is the way we learn. The course has been very well thought, every new capabilities is built on what has been previously learned.

If I were to do this all by myself, I'd usually look up the industry standard, and aim for the mountain top. In our case here, it'd probably be Ruby on Rails for making web apps.

In doing so, I'd be cutting off the (seemingly) unnecessary steps. But it would make the whole process to be much more difficult. Let's go through a few of these steps that allowed me to climb a bit higher every day.

From Sinatra to Rails

I remember when we were introduced to Sinatra. We learned about HTTP requests at the same time. I had a general good sense of how the way internet worked, but doing it myself was a revelation ; it felt like new doors of possibilities opened up to me.

And yet, the first day of our in person class we replaced Sinatra with Rails. Now I understand that Sinatra can have its use case, for smaller apps, or apps where we don't need such a strict layout of files.

But moving forward, Rails will probably be the go to framework for web app development. But it wasn't lost. If I were to be digging in Rails while learning about HTTP and routing at the same time, it would have been exponentially more difficult. So I am grateful that people have thought through it, and trail blazed the way for us.

From SQL commands to Active Records

This process of building upon what was just taught just keeps going on and on with every new day that goes by. The next one is database interactions.

While being introduced to Rails, we learned about basic SQL commands. I've try to polish my understanding and get some muscle memory in by practicing on SQLZoo and the Firstdraft in-house exercises.

Quickly after that though, we were introduced to Active Records, which is built in Rails and facilitates interactions with databases.

Having gone through the process of working directly with databases through SQL, it made me more comfortable with working with Active Records because I have some sense of what is happening in the back-end.

Relationship databases: one-to-many, many-to-many

Speaking of database, I've worked with large data in my previous jobs, mostly with Excel. I would sit there behind the computer, and think of the best way to organize it. For the most part, I would come up with something fairly good and usable. But there were some cases I found hard to manage, and I never quite knew why they were different until now.

Putting words on the concepts of a one-to-many and a many-to-many relationships was truly eye-opening. For the latter, I discovered a third, "hidden" table (the join table). I also understood why some data type were giving me trouble to organize: they were describing a many-to-many relationship, and I was constraining myself with two tables, not knowing the existence of the join table.

Refactoring

When learning how to code, it is hard to find the right balance between laying solid foundations, and aiming for clean, industry standard code.

In this course, we learned to write code mostly from scratch. When we needed to find the director for a movie, we'd use a .where() method to match the id from the Director table. It's can be long and repetitive.

And then after typing these for the n-th time, we learned to set up our own class methods to do this more easily. I do know now though, looking back, that this was the right way. If I was taken straight to this point without the grinding, it would probably take me more time down the road to fully understand what is going on.

Association Accessors

Take the previous point, and throw in Rails built in Association Accessors method like belongs_to or has_many.

Even though I had written these class methods before, when I first was reading about the Association Accessors it felt like climbing up a very steep hill.

But then because we had spent time writing these, and the exercise was narrowed to a quick refactoring, it made it so much easier to understand.

Learning to learn

Learning can be a painful process at times. Good mentorship is key, and concepts broken down in strategic bits is really impactful in how we learn.

With these conditions, learning feels like a game. Every day, I unlock new capabilities, and I just want to keep playing and keep unlocking the next thing.

TIL: Best Practices for Handling Secret Keys in Sinatra - The Do's and Don'ts

Thierry Chau — Fri, 28 Jul 2023 16:19:27 +0000

Introduction

As developers, we often find ourselves dealing with sensitive information like API keys. Sinatra, a lightweight Ruby web framework, offers an excellent platform for creating robust applications. However, when it comes to managing secret keys, it's essential to follow best practices to ensure the security and integrity of our applications.

In this TIL post, we will explore the insights I gained about secret keys in Sinatra. We'll delve into the dos and don'ts of handling sensitive information, the importance of using environment variables, and the risks associated with exposing secret keys.

I asked dezgo to generate an illustration for this blog post.

1. 1. What is an API?

From Wikipedia:

An API (Application Programming Interface) is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software.

For example, Google Maps has an API which allows us developers retrieve information they have gathered about the location of our choice. A URL request looks like this:

maps_url = "https://maps.googleapis.com/maps/api/geocode/json?address=INPUT_LOCATION&key=#YOUR_API_KEY"

Pirate Weather is another API. Together with Google Maps, we were able to develop an application which asks the user for a location, and provides coordinates, temperature, and a suggestion of whether or not to bring an umbrella!

umbrella main % ruby umbrella.rb 
Will you need an umbrella today?
Enter your location:
Chicago, IL
Checking the weather at Chicago, IL...
"Your coordinates are 41.8781136, -87.6297982."
It is currently 73°F (23°C)
Clear for the next hour.
Hours from now vs Precipitation probability


65|                                  * 
60|                               *  * 
55|                               *  * 
50|                               *  * 
45|                            *  *  * 
40|                            *  *  * 
35|                            *  *  * 
30|                         *  *  *  * 
25|                         *  *  *  * 
20|                      *  *  *  *  * 
15|                   *  *  *  *  *  * 
10|                *  *  *  *  *  *  * 
 5|                *  *  *  *  *  *  * 
 0+------------------------------------
    1  2  3  4  5  6  7  8  9 10 11 12 

You might want to take an umbrella!

One of the most famous API currently is probably Open AI, which allows developers to use and tweak the power of Chat GPT for custom applications. One example of this is an AI powered TA that is customized to provide software development specific answers (and more specifically in Ruby).

1. 2. What are these API Keys?

APIs are used to enable controlled access to a service or application's functionality and data. To regulate access and ensure security, APIs often require authentication or authorization. This is where API keys come into play.

An API key is a unique identifier issued to developers or applications that want to access an API. It acts as a secret token that grants permission to interact with the API and access its features or data. The API key is typically included in the request headers or parameters when making API calls.

More importantly, these API services are usually not provided for free. API keys is a way to track usage, and bill accordingly. For this reason, developers need to carefully handle their API keys and not let other people have access to it.

2. Understanding Secret Keys and Environment Variables

Environment variables allow us to do just that. These variables are read using the ENV.fetch() method, which retrieves the value of the environment variable based on its name.

The beauty of using environment variables is that they remain stored on the server where the application runs, making them inaccessible to users visiting the website. As long as we do not display, send, or log these variables inappropriately, they stay securely hidden from prying eyes.

3. 1. Caution with Development Gems

Even when correctly stored as environment variables, secret keys can be exposed with the use of development gems, such as better_errors (which provide enhanced error pages during development). While these gems are beneficial during development, they should not be used in production environments due to their potential to expose sensitive information during errors.

3. 2. Gemfile good practices

One way to avoid this is by separating gems by environment with the group :environment syntax. This is important as it ensures that certain gems are only loaded in the appropriate environments. A Gemfile could look like this:

gem "sinatra"
gem "sinatra-contrib"
gem "http"

group :development do
  #gem "better_errors"
  gem "binding_of_caller"
end

group :development, :test do
  gem "pry"
end

When deploying to production, it’s crucial to set the RACK_ENV or RAILS_ENV environment variable to production. This will ensure that only the necessary gems for that environment are loaded.

As a rule of thumb, any gem that provides debugging or testing capabilities should not be used in your production environment.

We can set this RACK_ENV directly in the command line when starting your server. For example:

RACK_ENV=production ruby app.rb

Conclusion

By using environment variables to store sensitive information, we ensure that these keys remain inaccessible to users visiting our websites.

Development gems used in production environments can result the accidental exposure of sensitive information. A properly set Gemfile can help avoid that.

By following these best practices, we can build secure and reliable Sinatra applications, protecting our users' data and maintaining the integrity of our code. Happy coding!

TIL the basics of Ruby

Thierry Chau — Fri, 21 Jul 2023 20:37:18 +0000

I dived right into learning Ruby these past few days, and it's been pretty exciting! I've learned a lot and here are a few bullet points to organize my thoughts about this journey

You can create your own classes in Ruby, and methods associated with it. There are instance methods and class-level methods. This is how it is done:

class New_class
  attr_accessor :attribute

  def method_class
    return #some method
  end

end

:attribute is a Symbol. They act like Strings but are unique, great for using as a key in Hash.

Ruby has a class Date that needs to be loaded. It allows manipulations on dates

require Date

pp Date.today
pp Date.parse("3rd Feb 2001")

Substracting two dates gives a Rational! It helps with getting accurate results as opposed to ‘Float’ and ‘Decimal’ objects which can produce inaccurate results because computers have limited memory. For this reason financial payment services always use Integers in their calculations.

Ruby has a large community with many programs available, called "gems". They can be loaded more easily with a "Gemfile" (no extension) with the following code:

source "https://rubygems.org"
# the following are examples of gem available
gem "activesupport"
gem "awesome_print"
gem "pry-byebug"

These are then installed all at once by typing bundle install in the terminal.

Github is an amazing ressource for programming. I have an IDE readily available online, it saves and keeps track of all my programming. I'm barely scratching the surface of it right now, and I'm sure there is much more to it.
rand is based off the Mersenne Twister algorithm. It generates random numbers from a seed value. This seed value can be called with srand, and by default is based on the computer's clock. For a given srand, rand will generate the same sequence of numbers. The rand is random enough for lower stake application, but can technically be predicted if one can observe 624 numbers in the sequence! For cryptography, the module SecureRandom is the way to go!
.sample uses rand to pick a random element in an array.
gsub can be used with a block. I learned this while trying to use a Hash for encrypting and decrypting a message:

def encrypting(secret)
  code = {
    "a" => "1",
    "e" => "2",
    "i" => "3",
    "o" => "4",
    "u" => "5"}
  return secret.gsub(/[aeiou]/i) { |match| code.fetch(match.downcase) }
end

TIL about interesting CSS resources

Thierry Chau — Tue, 18 Jul 2023 04:15:45 +0000

While slowly progressing through TechPrep, I found out about some very cool resources to practice CSS.

Here are some of my favorite ones.

Flexbox Froggy

It is kind of silly but also so useful. I will probably get back to it several more times until it sticks.

Also learned some interesting things about CSS : when setting the direction to reverse, start and end are also reversed. It makes sense, but good to know!

#pond { display: flex; flex-direction:row-reverse; justify-content:flex-end; }

Although, reversing the row does not reverse start and end for align-items. Makes sense also!

Happy Hues

Super neat tool to give some nice color associations, with all the HEX code needed implemented within previews!

pocoloco: to generate a dynamic background

TIL about inline CSS in html... and went down a rabbit hole

Thierry Chau — Sat, 15 Jul 2023 05:22:13 +0000

Not much happening today, but I got curious about how web browsers read html and CSS under the hood...

This spring I went through FreeCodeCamp's "Responsive Web Design" module, learning about html and CSS for the first time. They guided me straight to "the right way" of setting up an external stylesheet.

For TechPrep 2.0, one of the module is to go through Codecademy introduction to CSS. Although they say right away that this is not necessarily useful, I learned that I could inject CSS code straight into an html page.

Which got me thinking: "is html and CSS just the same language?"

I asked GP-TA, whose response was:

Yes, HTML and CSS are indeed two distinct languages, each with their own syntax, rules, and purposes.
HTML (HyperText Markup Language) is a markup language used for creating the structure and content of a webpage. It consists of various elements or tags that represent different types of content - headings, paragraphs, links, images, etc.
CSS (Cascading Style Sheets), on the other hand, is a style sheet language used for describing the look and formatting of a document written in HTML. It deals with the presentation aspects like layout, colors, fonts, etc.
The fact that you can write CSS inline within an HTML document doesn’t make them the same language. It’s just a way to apply CSS styles directly to HTML elements. However, it’s generally recommended to separate your CSS into its own file or at least in a style tag in the head of the document to keep styles separate from content, which makes your code more maintainable and easier to understand.
In other words, HTML and CSS work together to create a complete web page, but they have different roles and are distinct languages.

Fair enough, but not entirely convinced.

This led me down a rabbit hole of googling how computers interpret html and CSS on a lower level...

Which led me to the concept of DOM trees. DOM stands for "Document Object Model". I think it has to do with how a web browser first reads through html code to understand the relationship and hierarchy within it. But it is getting late here and I am not reinventing the internet tonight...

A DOM tree

Edit: I kept on reading. Turns out, there is a sister tree, the CSSOM (CSS Objet Model)(and then I think also more trees for Javascript???). And then the browser processes a render tree (so at this point it's basically a forest) which is basically how the trees are related to each other [insert mindblown emoji].