DEV Community: Jonathan Frias

Do you really understand authorization?

Jonathan Frias — Sun, 10 Nov 2024 19:09:57 +0000

Pretty much every web application handles authorization, and there are so many different libraries. How do you pick the right one? You're about to find out.

Fundamentally, authorization is a matching game to determine if some actor is allowed access to some resource. There's many ways to skin the cat, but they all follow the rules. Here are my rules:

Authentication presumes authorization. Null Object pattern is your friend here. You can absolutely make a Guest or Anonymous user with no access to anything. There isn't any reason to treat unauthorized users differently besides native language support for nil.
Authorization systems are written from either perspective: the user, or the resource.
Any arbitrarily complex authorization code can be constructed by the basis of the following 5 concepts:

Users (You, customer, external system)
Groups (This is a collection of users)
Permissions (CRUD+, standard CRUD plus whatever)
Roles (This is a collection of Permissions)
Resource (Anything! A record, a method, object etc)

In this mental framework Groups are just a collection of users and can be recursively defined. A group can be a tree of groups. Same with Roles.
A Role being a collection of permissions was a bit jarring at first, but think about it for a bit, and you'll realize it's true. There's quite a few of libraries that use role when instead of permission so be careful.

Now you have a solid mental framework to quickly review authorization options based on the trade offs that are being made by any particular library. I have yet to see any authorization library that supports all of them at the same time.

Let's review a few popular ruby gems and we'll see the trade-offs using this framework

CanCanCan
Pundit
Apartment
acts_as_tenant

CanCanCan

Let's look at cancan/cancancan, a popular gem originally created by the infamous Ryan Bates.

Straight from the README:

class Ability
  include CanCan::Ability

  def initialize(user)
    can :read, Post, public: true

    return unless user.present?  # additional permissions for logged in users (they can read their own posts)
    can :read, Post, user: user

    return unless user.admin?  # additional permissions for administrators
    can :read, Post
  end
end

You can immediately see the tradeoffs in the short example.

users	groups	permissions	roles	resource	auditable	complexity
✅	❌	✅	❌	✅	❌	low

CanCanCan supports users, permissions, and resources, limited support for auditing support, shallow learning curve, fail closed access via load_and_authorize_resource

CanCanCan works from the "perspective" of the user.

Supporting groups of users, or roles is left to the developer to implement.

Pundit

users	groups	permissions	roles	resource	auditable	complexity
✅	❌	✅	❌	✅	✅	medium

Pundit works from the perspective of the resource via policies.

Via policies, Pundit supports resources, users, auditing, a bit complex, permissions, fail closed via after_action :verify_authorized

Supporting groups of users, or roles is left to the developer to implement.

Apartment

users	groups	permissions	roles	resource	auditable	complexity
✅	✅	❌	❌	❌	✅	high

Advertised as "Multitenancy for Rails and ActiveRecord" means it supports groups. It does so via database replication/sharding/schema_search_path.

This design means that it supports users, groups, and resources, and is trivially auditable. fail open/close depends on how you handle your database connections/search path, and has a steep learning curve and maintenance burden.

It does not support permissions, roles.

acts_as_tenant

users	groups	permissions	roles	resource	auditable	complexity
✅	✅	❌	❌	✅	✅	low

This gem uses the ActiveRecord's default_scope to filter out records based on the group. It is quite an elegant solution, even though it doesn't solve permissions, nor roles.

There are various other role based authorization gems that have similar trade-offs. (Spoiler: They never support groups)

If only there was a gem that supported it all:

Trivial to use
Groups
Users
Roles
Permissions
Trivial to Audit
Fail-closed design
Can work from the perspective of a user or resource

That gem doesn't exist.. yet

Fearless Multitenancy

Jonathan Frias — Sat, 07 Oct 2023 04:26:12 +0000

Most Rails apps have an authentication feature. In those apps, the vast majority of work is done within the context of an authenticated user. This is so prevalent that Rails developers create separate spaces for unauthenticated public views and controllers.

Data access becomes a concern as a natural consequence of having multiple users. By default, when you load a Post or similar you have to remember to filter by some condition Post.where(user: current_user), you have always remember to filter for which records your current_user has access. I've seen solutions around the internet that go to extreme lengths to avoid data sharing and exposure. For example, authorization layering, customer data shards, separate schemas, and the Apartment gem.

These solutions all have the same problem. They are complicated. With multiple databases, schemas, and shards it starts to feel like you're maintaining multiple apps. You have a ton of big data problems when you might not even have big data to begin with. If you use an Authorization layer, it's error-prone, and writing a ton of tests is the only way to have any confidence that you aren't sharing data between customers. That takes a ton of time and patience. Do you really want to keep passing the user around?

Wait a minute!? Those solutions aren't extreme you say. Well, they all sound extreme to me when you realize that all those solutions can be rendered obsolete by a single global variable.

Big claims, so let's back them up with some code:

class Current < ActiveSupport::CurrentAttributes
  attribute :user
end

# ActiveRecord
module CurrentUserFilterable
  def self.included(base)
    base.send(:default_scope, -> () do
      raise "No Current.user!" unless Current.user
      # Exclude the system user from this constraint
      return self if Current.user.system?
      where(user: Current.user)
    end)

    base.belongs_to :user, default: -> { Current.user }
  end
end

# Here's a version if you use Sequel instead:
module CurrentUserFilterable
  def dataset
    raise "No Current.user!" unless Current.user
    return super if Current.user.sysetm?
    super.where({
      Sequel[@dataset.first_source_alias][:user_id] => Current.user.id
    })
  end

  def before_save
    self.user_id = Current.user.id
  end
end

And in any resource that needs such protection with a user_id:

class Post < ApplicationRecord
  include CurrentUserFilterable
end

Yes, this code uses a global variable for control access inside of ActiveRecord's default_scope. Give yourself a minute to get over the initial shock. This seems restrictive. This seems like a loss of control. This seems like bad code. After all, we are combining two patterns that are widely considered as problems together at the same time: Global State, and ActiveRecord default_scope.

I have fallen to the allure of default_scope and deeply regretted it so much so that I stopped using it and happily didn't look back until now.. more than 5 years later. The problem is always that it's nigh impossible to write certain features because there are always exceptions to your default scope, and you can get into situations where it's impossible to proceed without getting rid of the scope or doing weird ruby things. That inflexibility is exactly what you want when dealing with security and data access. It becomes so hard to share data that it will not happen by accident.

Instead of thinking of thinking of default_scope as a bad design, think of it as good security. Clients always want control over who can access data.

Imagine all the things you no longer have to do. You no longer have to remember to always add .where(user: current_user) to your queries removing an entire class of bugs from your data fetching layer. You no longer have the pain of running migrations multiple times for many different targets. You no longer have to write a ton of Rspec just to have confidence that you aren't leaking any data. You no longer need to rely on the apartment gem or another complex multitenant strategy.

You need a bit of supporting code to make this approach viable. Let's start with our ApplicationController. You need to make sure it's set at the start of a request:

class ApplicationController < ActionController::Base
  before_action :set_current_user
  private

  def set_current_user
    Current.user = current_user
  end
end

Since this change will also affect your Rails console, let's add a warning upfront:

# config/initializers/current_user_reminder.rb

Rails.application.console do
  puts "****************************************"
  puts "** You are not logged in. To login,   **"
  puts "** the following methods available:   **"
  puts "** - admin                            **"
  puts "** - anon (anonymous)                 **"
  puts "** - sys                              **"
  puts "** - Current.user = User.find(?)      **"
  puts "****************************************"

  def admin
    puts "logged in as admin"
    Current.user = User.find_by(email: "admin@example.com")
  end

  def sys
    puts "logged in as system"
    Current.user = User.find_by(some_system_condition: true)
  end

  def anon
    puts "logging out"
    Current.user = nil
  end

  # Uncomment to log in automatically
  # admin

end

Finally, in any jobs or mailers, you will need to pass the user that you are acting as. My recommendation is to pass it as the first argument.

NotifyPostPublishedJob.perform_later(Current.user, post)
UserMailer.weekly_articles(Current.user).deliver_later

Just for completeness, you might not cross boundaries by User, you could just as easily replace User with your Organization or Team or Company model and achieve a similar effect.

Hopefully, you can see that you align your core application with your business goals. This solves a base problem in multitenancy, but it doesn't solve authorization requirements within a tenant. Since, I've never really been 100% satisfied with any of the authorization gems in the Rails community so watch out for my next post where we approach this problem formally, and expose the issues with every single authorization gem.

If you like these ideas and would like to work with me, drop me an email at contact@gofrias.com.

When globals are appropriate

Jonathan Frias — Mon, 02 Oct 2023 15:43:14 +0000

There are times when globals make sense. A lot of people talk about the dangers of global variables and I agree that they should be used sparingly. It's a discussion that's been had over and over again. But let's see if we can decide a rule for when we are willing to allow ourselves to use a global.

So what is a "global"?

A global is a shared resource that can be accessed at any time, from anywhere. Since this type of access breaks many conventional notions of good software engineering, they are usually dismissed as bad. The mere existence of a global indicates an elevated sense of importance. In a way, the only way to express this criticality is in the form of a global.

Globals must align with the essence of the software. Such that when removed or rendered impossible, you would abandon the project, or it would become a different project entirely.

Let's talk about ruby. There are a few standard integrations that are essential to the functionality of the software and they are elevated to the status of global. If you use the fantastic Sequel gem, the README literally recommends you assign the connection to the database as a global. This communicates that database interop is so essential to what you're working on that there's no point in abstracting it away behind any other layers. If somehow it became forever impossible to access the database, there's a reasonable chance you would abandon or pivot the entire project. When you have a concept THAT important, you are allowed to make it global. If you use Rails, there is already built-in support

Integrations can be a special case

There's a lot of code that exists simply to integrate into other services. If you are making a salesforce app integration, your salesforce client can be global. Why? You can build your plugin with standard techniques, but by its very nature, it will always depend on Salesforce or be obsolete. If you accept that as part of the essence of what you're working on, you can sidestep a ton of extra architecture and design and just be productive.

I haven't seen any other justifiable uses of globals, and I still tend to steer clear of them, however, I hope this gives you a different perspective on the subject.

If you like these ideas and would like to work with me, drop me an email at contact@gofrias.com

Handling Timezones in Rails

Jonathan Frias — Wed, 21 Jun 2023 04:10:29 +0000

The missing guide to handling timezones in Rails and PostgreSQL.

I wanted to write this guide to be your new default practice to handling time zones in Ruby on Rails. This was a hard-won lesson I learned from working a calendar scheduling app a few years back. I want you to stop converting time in your application. This is already a solved problem, no need for Rails devs to do it!! I know you have the sneaky timezone converter code, and it needs to go!

I always read on the internet that your application should use UTC for all the database related time zone information, but there is some setup that is needed in order to realize the effectiveness of this practice.

First things first, postgres itself recommends that you not store UTC timestamps with a timestamp type. Instead you should use a timestamptz type. See: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

Now that rails has finally set up a configurable option to generate migrations with the appropriate types (See: https://github.com/rails/rails/pull/41084, https://github.com/rails/rails/pull/41395)
These posts outline the core of the problem. We want to use timezones, and we want ActiveSupport::TimeZone, ActiveSupport::TimeWithZone, DateTime, Time to all work together as they are supposed to.

If you read the above referenced links, you'll see that this subtly and changes the types and some of the behaviors of the time zones. These are all unfortunate results of the mess we have made. Since it's impossible for Rails to know what time zone you intended. Keep this in mind as you upgrade your timezones columns.

When you store regional timestamps without the timestamptz information, it forces you as an application developer to coerce this type into the appropriate zone for the user. What this essentially means is that in application code, you're going to have something that perhaps calculates the difference of hours between your client's timezone and your database default of UTC time. This is the normal default response, but there's a better way.

Instead do this. Set a few fallbacks for where your default application timezones should live. For example you can detect the location of the client ip address and use that to determine their default time zone. Here I just pick my own timezone to be the default.

Then you store all of your created_at, updated_at and whatever_at time information inside of a the appropriate timestamptz, and you allow the timestamp to come from where it really belongs.

default application time zone (Maybe your HQ time zone)
User defined timezone (This is a string column named timezone on your user model)
Resource defined timezone (This is a string column named 'timezone' on your non-user model)

Here's a helper method that can pretty easily be generalized or converted into a mixin/module as needed:

class Event
  def started_at
    super.in_time_zone(time_zone)
  end

  def finished_at
    super.in_time_zone(time_zone)
  end

  def time_zone
     ActiveSupport::TimeZone[super] || default_timezone
  end

  def default_time_zone
    ActiveSupport::TimeZone["Pacific Time (US & Canada)"]
  end
end

class User
  def time_zone
    ActiveSupport::TimeZone[super] || default_time_zone
  end

  def default_time_zone
    ActiveSupport::TimeZone["Eastern Time (US & Canada)"]
  end
end

Note that by going through ActiveSupport::TimeZone#[], I can always ensure that I am dealing with a valid time zone. It's free tz validation!

List available timezones:

ActiveSupport::TimeZone.all.map(&:name)

Now when I have an event provided by Event.first.started_at, I will always have an event that's in the correct time zone for the event, and in my view code I can simply override per user/guest with:

# Handles if the user is a guest
event.started_at.in_time_zone(current_user&.time_zone || event.time_zone)

By doing it this way, I always store data the way postgres recommends, I only work with time zone aware data types, and convert between time zone aware types, all while at the time time respecting the time zone of whoever created the original resource. For these cases, you have options when setting what the time_zone should be:

Ask the user what time_zone they want the Event/resource to be
Sensibly assume the resource is in the same time zone as the user manually set in their profile
Guess time zone based on ip geolocation
Fallback to some application default

Either way, you follow the best practices:

Store your time information in timestamptz by default
Store the time_zone with the resource that it belongs to
Have a sensible default case

Thank you for reading.