DEV Community: Paweł Pacana

Explaining Rack — desugaring Rack::Builder DSL

Paweł Pacana — Thu, 22 Apr 2021 16:32:07 +0000

Yesterday I wrote a post highlighting Basic Auth and how can we protect Rack applications mounted in Rails with it.
Today when discussing some ideas from this post with my colleague, our focus immediately shifted to Rack::Builder.

On one hand Rack interface is simple, fairly constrained and well described in spec. And ships with a linter to help your Rack apps and middleware pass this compliance.

A Rack application is a Ruby object (not a class) that responds to call. It takes exactly one argument, the environment and returns an Array of exactly three values: The status, the headers, and the body.

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end

On the other hand your first exposure to Rack is usually via config.ru in Rails application:

# This file is used by Rack-based servers to start the application.

require_relative "config/environment"

run Rails.application

Behind the scenes, this file is eventually passed to Rack::Builder. It is a convenient DSL to compose Rack application out of other Rack applications. In yesterday's blogpost we've seen it being used directly:

Rack::Builder.new do
  use Rack::Auth::Basic do |username, password|
    ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(username), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_USERNAME"))) &
      ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(password), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_PASSWORD")))
  end
  run Sidekiq::Web
end

Whether you use Rack::Builder directly or via rackup files, you're immediately associating Rack with the use and run DSL.
And that triggered an honest question from my colleague — how does this DSL relate to that rather simple Rack interface?

De-sugaring Rack::Builder DSL

To add even more nuance, some Rack apps are called a middleware. What is a middleware? In simple words — it's a Rack application that wraps another Rack application. It may affect the input passed to the wrapped app. Or it may affect the output if it.

An example of a middleware that makes everything sound more dramatic:

class Dramatize
  def initialize(app)
    @app = app
  end

  def call(env)
    status, headers, body = @app.call(env)
    [status, headers, body.map { |x| "#{x}111one!1" }]
  end
end

A composition of such middleware and our previous sample HelloWorld application with config.ru would look like this:

# config.ru

class HelloWorld
  # omitted for brevity
end

class Dramatize
  # omitted for brevity
end

use Dramatize
run HelloWorld.new

When executed, it would return very dramatic greeting:

$ bundle exec rackup config.ru
* Listening on http://127.0.0.1:9292
* Listening on http://[::1]:9292
Use Ctrl-C to stop

$ curl localhost:9292                                                    
Hello world!111one!1⏎

Now back to the question that started it all:

How does this DSL relate to that rather simple Rack interface?

The last example of composition via Rack::Builder can be rewritten to avoid some of the DSL:

# config.ru

run Dramatize.new(HelloWorld.new)

A single run is needed to tell a Ruby application server what is our Rack application that we'd like to run. The use of use is on the other hand just optional.

If this post got you curious on Rack, a fun way to learn more about it is to check the code of each middleware powering your Rails application:

$ bin/rails middleware
use Webpacker::DevServerProxy
use Honeybadger::Rack::UserInformer
use Honeybadger::Rack::UserFeedback
use Honeybadger::Rack::ErrorNotifier
use Rack::Cors
use ActionDispatch::HostAuthorization
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActiveSupport::Cache::Strategy::LocalCache::Middleware
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use ActionDispatch::RemoteIp
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::ActionableExceptions
use ActionDispatch::Reloader
use ActionDispatch::Callbacks
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ContentSecurityPolicy::Middleware
use ActionDispatch::PermissionsPolicy::Middleware
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Rack::TempfileReaper
use Warden::Manager
use Rack::Deflater
use RailsEventStore::Middleware
run MyApp::Application.routes

Happy learning!

Rack apps mounted in Rails — how to protect access to them?

Paweł Pacana — Wed, 21 Apr 2021 23:07:26 +0000

Sidekiq, Flipper, RailsEventStore — what do these Rails gems have in common? They all ship web apps with UI to enhance their usefulness in the application. Getting an overview of processed jobs, managing visibility of feature toggles, browsing events, their correlations and streams — nothing you could not do in code or Rails console already. But never really wanted to do there 😉

In Rails apps we add those UI apps with mount in routing:

# config/routes.rb

Rails.application.routes.draw do
  mount Sidekiq::Web, at: "/sidekiq"
end

In production application you'll want to protect access to this Sidekiq dashboard. Let's assume this Rails application is API-only. There's no Devise nor any other authentication library of your choice there. Fair scenario to rely on HTTP Basic Auth, as illustrated with wonderfully commented example from Sidekiq wiki:

# config/routes.rb

Rails.application.routes.draw do
  Sidekiq::Web.use Rack::Auth::Basic do |username, password|
    # Protect against timing attacks:
    # - See https://codahale.com/a-lesson-in-timing-attacks/
    # - See https://thisdata.com/blog/timing-attacks-against-string-comparison/
    # - Use & (do not use &&) so that it doesn't short circuit.
    # - Use digests to stop length information leaking (see also ActiveSupport::SecurityUtils.variable_size_secure_compare)
    ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(username), ::Digest::SHA256.hexdigest(ENV["SIDEKIQ_USERNAME"])) &
      ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(password), ::Digest::SHA256.hexdigest(ENV["SIDEKIQ_PASSWORD"]))
  end

  mount Sidekiq::Web, at: "/sidekiq"
end

Let's transform this example a bit to not rely on Sidekiq::Web.use. That's very convenient to provide such interface from a library. I want to show you something else here — Sidekiq::Web is a Rack application and can be treated as such.

# config/routes.rb

Rails.application.routes.draw do
  mount Rack::Builder.new do
    use Rack::Auth::Basic do |username, password|
      ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(username), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_USERNAME"))) &
       ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(password), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_PASSWORD")))
    end
    run Sidekiq::Web
  end, at: "/sidekiq"
end

Little explanation:

Rack::Builder is a DSL to create new Rack application
Rack applications can wrap each other, like layers
when the request comes in, a chain of Rack apps is executed from outermost to innermost
when the response is to be returned, it goes from innermost Rack app to outermost

Right. Wasn't it supposed to be about protecting access?

Imagine now that aforementioned Rails application includes all those UIs for Sidekiq, Flipper, RailsEventStore at the same time. How can we have common protection for them without boring copying and pasting same wrapper again and again?

Let's extract (bad word detected) a factory!

# config/routes.rb

Rails.application.routes.draw do
  with_dev_auth =
    lambda do |app|
      Rack::Builder.new do
        use Rack::Auth::Basic do |username, password|
          ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(username), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_USERNAME"))) &
            ActiveSupport::SecurityUtils.secure_compare(::Digest::SHA256.hexdigest(password), ::Digest::SHA256.hexdigest(ENV.fetch("DEV_UI_PASSWORD")))
        end
        run app
      end
    end

  mount with_dev_auth.call(Sidekiq::Web), at: "sidekiq"
end

Fun fact is that a Proc#[] is an equivalent to Proc#call.
The last line can be as well written as:

  mount with_dev_auth[Sidekiq::Web], at: "sidekiq"

And with all those UIs in place we receive:

  mount with_dev_auth[Sidekiq::Web],             at: "/sidekiq"
  mount with_dev_auth[RailsEventStore::Browser], at: "/res"
  mount with_dev_auth[Flipper::UI.app(Flipper)], at: "/flipper"

In the future we could swap Basic Auth to one or another authentication mechanism. The with_dev_auth factory would remain useful and probably survive them all.