When it comes to building robust and flexible applications with Ruby on Rails, adopting practices that allow for easy future changes can save developers a significant amount of time and hassle. One such practice involves the strategic definition of enums in your Rails models. Enums are a way to map attribute values to human-readable names, making your code more readable and easier to manage. However, defining these enums requires foresight, especially if your application is expected to evolve over time.

Consider a CheckupEvent model in a healthcare application, where various types of events need to be tracked, such as the start, pause, resume, and end of a checkup. A straightforward approach might define these event types with consecutive integer values, like so:

1
2
3
4
5
6
7
8
class CheckupEvent < ApplicationRecord
  enum event_type: {
    start: 1,
    pause: 2,
    resume: 3,
    end: 4
  }
end

This approach is simple and works well initially. However, what happens when we need to introduce new event types in between existing ones? For instance, if we wanted to add a delay event between start and pause, our numbering scheme would already be locked in, making it tricky to maintain a logical order without altering the existing values (which could be a risky operation if the data is already in use).

A more flexible approach involves spacing out the integer values assigned to each enum name right from the start:

1
2
3
4
5
6
7
8
class CheckupEvent < ApplicationRecord
  enum event_type: {
    start: 0,
    pause: 2,
    resume: 4,
    end: 6
  }
end

By doing so, we allow ourselves room to grow. If the need arises to introduce new event types into our application, we can easily slot them in between the existing values without disrupting the sequence. For example, adding a delay event type with a value of 1 fits perfectly between start (0) and pause (2).

This method of defining enums offers several benefits:

1. Flexibility: It’s easier to introduce new options without affecting existing data or requiring complex data migrations.
2. Maintainability: The codebase remains clean and understandable, even as it evolves.
3. Scalability: Your application can grow more seamlessly, accommodating new features or changes in business logic with minimal friction.

In summary, while the traditional consecutive numbering for enums might seem simpler at first, spacing out integer values offers a forward-thinking approach. It anticipates changes and expansions to your application, making future developments smoother and less prone to error. So, next time you define enums in your Rails models, consider leaving yourself a little room to grow. It’s a small step that can make a big difference in the long run.

In the realm of software development, venturing into the less conventional paths can sometimes reveal the most efficient and elegant solutions. Today, I’m excited to share my experience with a unique edge scenario in Ruby on Rails. This particular challenge involved a form integrated with the Stimulus Rails Autosave component, and the solution I devised might seem unconventional at first glance, yet it was perfectly suited for the task at hand. Let’s explore the code that made this possible and the thought process behind my approach.

The Challenge at Hand

The task was straightforward yet nuanced: to manage the creation or deletion of a FindingArea object in response to user interactions, all within a form leveraging the Stimulus Rails Autosave component. The solution needed to be efficient, clean, and maintainable.

The Code

Here’s the Ruby on Rails code snippet that stands at the core of the solution:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class V2::Assessments::FindingAreasController < ApplicationController
  def create_or_destroy
    options = {"true" => :create, "false" => :destroy}
    choice = params[:finding_area][:persist]
    send options[choice] || :bad_request
  end

  def create
    FindingArea.create(finding_id: params[:finding_id], area_id: params[:area_id])
    head :no_content
  end

  def destroy
    @finding_area = begin
      FindingArea.find_by(finding_id: params[:finding_id], area_id: params[:area_id])
    rescue
      nil
    end

    if @finding_area&.destroy
      head :no_content
    else
      head :bad_request
    end
  end
end

This code showcases the method I adopted to dynamically handle the creation or destruction of FindingArea instances, based on the user’s input, all within a single controller action.

My Thought Process

The integration with the Stimulus Rails Autosave component offered two paths:

1. Directly instructing the controller to either create or destroy a finding_area.
2. Employing a turbo_stream to ascertain the required controller action and path, based on the finding_area.

I opted for the first route for several reasons:

• Clarity: Directly linking user actions to controller responses allowed for a transparent and straightforward flow.
• Simplicity and Maintainability: This approach resulted in cleaner and more manageable controller logic, essential for the longevity and scalability of the application.

Although this method slightly strays from the Rails conventions, it resonated with the application’s requirements and the Stimulus Rails Autosave’s functionality, striking a balance between simplicity and efficiency.

Reflecting on the Solution

Choosing an unconventional path in Rails was a testament to the flexibility and adaptability required in software development. This experience reaffirmed that sometimes, the most straightforward solutions, though atypical, can be the most effective. The key takeaway from this journey is the importance of tailoring solutions that align with the specific needs of the application while ensuring code clarity and maintainability.

In the landscape of software engineering, such instances serve as valuable learning opportunities, encouraging us to think outside the box and approach problem-solving with an open mind. Ultimately, it’s about finding the balance that best suits the unique demands of your project, ensuring that the code remains elegant, functional, and straightforward.

TL;DR - Rails Session Cipher - A gem to decrypt (and encrypt!) Rails’ session cookies.

Introduction

In a recent project, our team utilized rack-attack gem to manage and throttle incoming traffic, aiming to mitigate potential harm from malicious entities. Considering the application is accessible only to logged-in users, it seemed logical to apply different throttling rules for authenticated users. However, a challenge arose: the methods like current_user from Devise are unavailable at the middleware level where Rack::Attack operates. My solution was to decrypt the Rails session cookie for identifying registered users. This post details my journey.

How Rails Session Cookies Work

Rails session cookies are pivotal for maintaining user sessions in a web application. They store session data on the client-side, ensuring a seamless user experience. The session data is encoded and secured with a server-side secret, making it tamper-proof.

• Encoding and Security: The session data is serialized and then encoded with Base64. Rails uses a secret key base for encryption, ensuring that the data cannot be read or altered without the key.
• Client-Side Storage: The cookie is stored in the user’s browser, allowing Rails to retrieve and decode it with each request, maintaining session continuity.

This mechanism is integral to how users interact with Rails applications, ensuring both security and functionality.

Decrypting Rails Session Cookie

Deciphering the Rails session cookie, though challenging given the Rails framework’s complexity, is possible. The decryption process hinges on understanding the encryption method used.

Encryption Process

Rails employs a sophisticated encryption process to secure session data.

• Step-by-Step Breakdown:
  1. Serialization: Session data is converted into a string format.
  2. Encryption: This string is encrypted using an AES cipher.
  3. Encoding: The encrypted data is then Base64 encoded for safe transmission via cookies.

Knowing this, we can reverse the process to access the session data.

Decryption Steps

The decryption process involves several critical steps:

1. Splitting the Cookie

The session cookie comprises three parts - an initialization vector, an authentication tag, and the encrypted data. We separate these using Base64 decoding.

1
2
3
data, iv, auth_tag = session_cookie&.split("--")&.map do |v| 
   Base64.strict_decode64(v)
end

The authentication tag is 16 bytes long, which aligns with the standard length for AES encryption, ensuring integrity and authenticity.

2. Setting Up the Cipher

We configure an OpenSSL cipher for decryption, using the same parameters as Rails for encryption.

1
2
3
4
5
cipher = OpenSSL::Cipher.new("aes-256-gcm")
iteration_count = configuration.iteration_count
salt = options[:salt] || configuration.salt
hash_digest_class = options[:hash_digest_class] || configuration.hash_digest_class
secret = OpenSSL::PKCS5.pbkdf2_hmac(key, salt, iteration_count, cipher.key_len, hash_digest_class.new)

This step includes generating a secret key using the same algorithm Rails uses, ensuring compatibility.

3. Decrypting the Data

We configure the cipher for decryption and process the encrypted data.

1
2
3
4
5
cipher.decrypt
cipher.key = secret
cipher.iv = iv
cipher.auth_tag = auth_tag
cipher.auth_data = ''

Finally, we decrypt the data and parse it into a readable format.

1
2
3
cookie_payload = cipher.update(data)
cookie_payload << cipher.final
JSON.parse(cookie_payload)

Integrating Decryption into a Gem

To maximize the utility and security of this decryption process, we encapsulated it into a Ruby gem. This approach offers several advantages:

• Community Oversight: Open-sourcing this functionality invites scrutiny and contributions, enhancing security.
• Ease of Integration: The gem can be easily integrated into any Rails project.
• Security through Obscurity: While the code is accessible, embedding it in a gem makes it less conspicuous in the application.

I encourage you to explore and contribute to the gem repository. Your feedback is invaluable, and if you find it helpful, please star the repo to aid others in discovering it.

Rails Session Cipher

In the world of healthcare tech, playing fast and loose with data security is a no-go. HIPAA isn’t just a guideline; it’s the heavyweight champ of privacy rules. So when I ran smack into the wall that is email attachment limits while trying to send elephant-sized PDF reports, I had to get creative. Stick with me here, and I’ll walk you through how a bit of Rails magic helped me juggle compliance and convenience without breaking a sweat.

The Premise: Size Matters, So Does Privacy

Transferring large PDF files securely is a non-negotiable aspect of handling healthcare information. The typical email attachment size cap of 30 MB was a constraint that my client could not afford to be shackled by.

The Rails Solution: Storing Big, Sharing Wisely

With Rails Active Storage and AWS S3, storing massive files was a breeze. However, the real game-changer was sharing not the file itself but a secure, time-restricted URL to the file via email, cleverly bypassing the size limitations.

Generating Secure Tokens: The Bedrock of Privacy

For heightened security, each user was assigned a unique auth_token. Rails’ SecureRandom.hex provided the robust, unguessable token we required.

1
2
3
4
5
6
7
8
# app/models/person.rb
before_create :generate_auth_token

private

def generate_auth_token
  self.auth_token = SecureRandom.hex(10) # Generates a unique and secure token
end

Thwarting Timing Attacks: Ensuring Equal Footing

Timing attacks are a form of side-channel attack where an attacker observes the time taken to execute cryptographic algorithms to determine potential vulnerabilities. In layman’s terms, they are the equivalent of a thief gingerly trying door locks, with each failed attempt subtly informing their next move.

In our implementation, guarding against such attacks was paramount. We used ActiveSupport::SecurityUtils.secure_compare to compare tokens in a way that prevents attackers from measuring how long it takes to validate their guesses.

1
2
3
4
5
6
7
# app/controllers/application_controller.rb
def authenticate_person!
  authenticate_or_request_with_http_basic do |username, password|
    person = Person.find_by(email: username)
    person.present? && ActiveSupport::SecurityUtils.secure_compare(person.auth_token, password)
  end
end

This method is meticulously designed to take the same amount of time to process, regardless of whether the tokens match or not, effectively rendering timing attacks useless.

Conclusion: A Fortress of Security

The final solution was a resounding success, ensuring that our client could email large PDF reports with confidence, knowing that the data remained secure and private, in compliance with HIPAA regulations. Through careful planning and robust programming, we turned a potential vulnerability into a showcase of security.

Remember, the nuances of coding are not just about creating functionalities but also about safeguarding the sanctity of the data we are entrusted with. In a world where data breaches are commonplace, let’s make our Rails applications bastions of security.

Code securely, and may your data remain impenetrable.

It started when I was reviewing a colleague’s PR. Something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class SomeJob < ApplicationJob
  def perform(...)
    # Logic stuff
    $slack.chat_postMessage(
      channel: channel_id, 
      blocks: build_blocks(channel_id, "some message")
    )
  end

  def build_blocks(channel_id, message)
    [
      {
        "type": "section",
        "text": {
          "type": "mrkdwn",
          "text": message,
        },
      },
      {
        "type": "actions",
        "elements": [
          {
            "type": "button",
            "text": {
              "type": "plain_text",
              "text": "Archive Now!",
              "emoji": true,
            },
            "style": "danger",
            "value": channel_id,
            "action_id": "archive_now",
          },
          {
            "type": "button",
            "text": {
              "type": "plain_text",
              "text": "Snooze 14 days",
              "emoji": true,
            },
            "style": "primary",
            "value": channel_id,
            "action_id": "archive_snooze",
          },
        ],
      },
    ]
  end
end

Any method like the one above should catch your eye. The blocks stuff seemed to be something particular from Slack. Indeed, it is the spec to build Slack’s blocks (units for Slack’s Block Kit system). Roughly, it lets you compose rich UIs with these blocks. Did this mean we needed to do this JSON stuff every time we wanted to build this UI type? It seemed brittle. There probably was a better way.

Layouts

Slack Block Kit reference docs don’t especifically set an abstraction with the name layout. But the word came to me as I inspected Christian Gregg’s gem slack-ruby-block-kit. I found Christian’s gem because I thought someone had to have built something out to build these blocks more quickly. Indeed, his gem did some heavy lifting and laid down the work to speed up building these blocks. However, it is essential to develop conventions when working with a team. That’s how I came up with the idea of the SlackLayout pattern—an interface to compose Block Kit “layouts” that can be easily reused and organized.

I released a gem in case anyone also thinks it can help: SlackLayouts.

It provides a parent class (SlackLayout) and a clear interface (#blocks) to access the layout intuitively and build the blocks you need without writing JSON or remembering slack-ruby-block-kit namespaces.

It also makes sense. Different classes (in Rails jobs, models) can use different layouts without having to couple it to the class itself.