Introduce Actionable Errors

[gsamokovarov]

The idea of actionable errors has been floating around for a few years. First
introduced by @vipulnsward in #26542 (thanks Vipul) and later on expanded
by @causztic and myself in this year's GSoC. The current implementation is the
result of the lessons we learnt from the previous ones and, I hope, provides
the simplest API and implementation.

---

Actionable errors let's you dispatch actions from Rails' error pages. This
can help you save time if you have a clear action for the resolution of
common development errors.

The de-facto example are pending migrations. Every time pending migrations
are found, a middleware raises an error. With actionable errors, you can
run the migrations right from the error page. Other examples include Rails
plugins that need to run a rake task to setup themselves. They can now
raise actionable errors to run the setup straight from the error pages.

Here is how to define an actionable error:

class PendingMigrationError < MigrationError #:nodoc:
  include ActiveSupport::ActionableError

  action "Run pending migrations" do
    ActiveRecord::Tasks::DatabaseTasks.migrate
  end
end

To make an error actionable, include the ActiveSupport::ActionableError
module and invoke the action class macro to define the action. Action
needs a name and a procedure to execute. The name is shown as the name of a
button on the error pages. Once clicked, it will invoke the given
procedure. An error can have multiple actions as well.

The actions are dispatched by simple forms. No XHR's or any JS involved in
the process. The current page address is remembered and if the action was
successful, the dispatching middleware will issue a redirect back to it.

This is because to make an "action progress" page we'd need to either:

1. Define an interface of the returned values of the action class macro.
2. Capture STD{OUT,ERR} and display it.
3. Probably something I'm missing... 😅

In any case, I think we can avoid all of the manutia around progress display and
do a simple post submission for now.

Here are a few screenshots of the error pages of actionable errors:

The builtin pending migrations error is now actionable

A custom actionable error with multiple actions

When an action fails

[robin850]

Awesome ! 🎉

[simi]

What's empty actionpack/lib/action_dispatch/middleware/templates/rescues/_actions.text.erb for?

[nynhex]

^great holiday pr

[gmcgibbon]

This is looking great @gsamokovarov! Really excited to see this in Rails 6!! 👏

[matthewd]

I'm disappointed to leave behind both stateful actions and any progress/output channel, but getting a solid foundation in sounds great.

[vipulnsward]

We can probably expand on what this does though, or what the end goal is that we get out of this?

[vipulnsward]

I see we actually expand this below, probably a one line note here would be great.

[kaspth]

I'm liking this a lot! Let me know if you need more reviews, I'll help you get this in for Rails 6 ❤️

[kaspth]

I don't think this location should know about the DatabaseTasks. How about we let action accept a command option instead? E.g.:

action "Run pending migrations", command: "db:migrate"

def action(name, command: nil, &block)
  _actions[name] = block || -> { Rails::Command.invoke command }
end

Although then Active Support knows about Rails commands… 😄

[kaspth]

Let's deal with this part later. I do like the idea that other libraries could extend action with their own behaviors ala:

# Somewhere in railties
ActiveSupport::ActionableErrors.register_behavior :command do |command|
  Rails::Command.invoke command
end

# Back in Active Support:
def action(name, **behaviors, &block)
  _actions[name] = block || extract_behavior(behaviors)
end

def extract_behavior(behaviors)
  if match = (behaviors.keys & self.class.behaviors.keys).first
    callable, value = self.class.behaviors[match], behaviors[match]

    -> { callable.call(value) }
  end
end

Hm, but then we'll have load order dependencies… 😅 Well, this was fun to think about! I still think we should find a way such that Migration doesn't know about the migrate task, but that's later.

[gsamokovarov]

Hey, yeah, I like that we can execute arbitrary code here now and we're not explicitly coupled with commands, but they are kinda easy to invoke if that's your desire.

[kaspth]

I thought we used the class NonActionable < StandardError; end style?

[gsamokovarov]

Okay, will change this.

[kaspth]

Should we put autoload :ActionableError beneath Concern instead and skip the require? Because this organization just nullifies the Concern autoload.

[gsamokovarov]

Seems good!

[kaspth]

I'll just reference #35489 in passing, though I'm still not sure if it changes anything for this.

[gsamokovarov]

Oh, @kaspth, haven't seen your round of comments. I will take a look at them and respond back in a bit.

[gsamokovarov]

@kaspth, @vipulnsward Sorry for taking me so long to get back to you. Can you folks take a "final" (final, final 😂) look?

[palkan]

🎉 🎉 🎉

[gsamokovarov]

✌️

[l33z3r]

Guys, I just checked my production logs and somebody crafted a request:

POST /rails/actions?error=ActiveRecord::PendingMigrationError&action=Run%20pending%20migrations&location=%0djavascript:alert(1)//%0aaaaaa

They were able to trigger an attempt at running migrations on my production environment.
Is this a massive security hole?

[gsamokovarov]

What rails version are you running on and do you happen to have config.consider_all_requests_local turned on in production? After #40689 the middleware should not be in the production middleware stack as well but this will happen in Rails 7.

[l33z3r]

I am running rails 6.0.2.2. I do not have config.consider_all_requests_local turned on in production. Seems that pull request will solve the issue. I just manually resolved it by removing the middleware in application.rb. thanks

[rafaelfranca]

That security hole was fixed in 6.0.3.2. GHSA-c6qr-h5vq-59jc. You should make sure your Rails version is up to date because that is not the only security issue that you have open in your app.

[l33z3r]

Ok, thanks for clearing that up. Yes, an update is on the cards

…

On Mon, Mar 22, 2021 at 7:54 PM Rafael França ***@***.***> wrote: That security hole was fixed in 6.0.3.2. https://github.com/advisories/GHSA-c6qr-h5vq-59jc. You should make sure your Rails version is up to date because that is not the only security issue that you have open in your app. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#34788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEFWF633NUPAWDYLVT45LTE6N5XANCNFSM4GMEPLZA> .