Allow short circuiting of request stages via filters

[jasonayre]

First off, really digging the framework overall, I like the simplicity and discoverability.

Ive been building a gem on top of it that fills in the gaps with some of the things I miss about rails (and making it more resourceful ala inherited resources),
https://github.com/jasonayre/traxis (if youre interested, awful name I know :D )

But anyways, heads up that I may be opening alot of issues in the near future, and some of them may just be stupid questions Im unable to figure out the intended operation of :)

SO:

biggest issue right now, is, I don't seem to see any ability to short circuit the request stages, i.e. in a before or after filter. Or at least I cant figure it out for the life of me.

I.E. I have an authentication concern:

module Concerns
  module Authenticated
    extend ::ActiveSupport::Concern

    included do
      after :validate do |controller|
        controller.current_user if controller.send(:action_requires_auth?)
      end

      after :response do |controller|
        controller.response = ::Traxis::Responses::Unauthorized.new if controller.send(:action_requires_auth?) && !controller.send(:current_user?)
      end
    end

    def action_requires_auth?
      request.headers.attributes.has_key?(:AUTH_TOKEN)
    end

    def current_user
      @current_user ||= ::User.find_by(:authentication_token => request.headers.attributes[:AUTH_TOKEN])
    end

    def current_user?
      current_user.present?
    end
  end
end

What Im trying to do is:

1. Only validate if the AUTH_TOKEN header is present (since Im setting that via a trait which I can include on demand on the action with use
2. If the auth token is present, find the user by auth token, set the iVar to the result of the query
3. if there is no user, short circuit the request stages with a Unauthorized response.

The above code is as close as I was able to get, but basically, because everythings happening in filters, I dont see any way to return the actual Response, trigger the request stage to render it (because it seems like thats what happens at soon as the request stages encounters a response object, if Im reading the code correctly)

So all I can see to do, is override the controller response, AFTER the action has ran (because otherwise my response Ive set will get overriden by a success response at end of chain)

which is of course an incredibly hacky solution, as the original controller action is still called.

So, I feel like I have to be missing something. I thought about making my own request stage in my gem and inserting for purposes of short circuitomg, but it doesen't seem to have any control over the order its inserted in (not like rack), so that would end up being hacky as well.

Any suggestions, or thoughts, if this functionality does not exist currently? (and maybe the answer is to do it in rack, but that kind of defeats the purpose of managing stuff like this as a trait)

[blanquer]

Jason,
First of all, thanks for the interest, and second, there isn't such a thing as stupid questions...more likely stupid answers. :)

So, you're basically delving into one of the green areas of Praxis, as most of our apps that use more powerful filters are still running atop our old version of the framework (which runs on top of Sinatra, which you probably know handles the request lifecycle in a very different manner).

So, yes, what you're asking is not quite there. Therefore, let's add it!
I have created a branch (21-controller_filter_shortcuts) that implements some of that functionality with the following things in mind:

• How do we allow the callbacks to shortcut the run? Returning a Response-based object seems reasonable as it seems a good way to signal both a way out, and also how to "exit". There are other ways like exceptions or throwing symbols like Sinatra, but I don't particularly thing those are what people would think most appropriate. I've chosen a Response-based return in the prototype branch as I don't think it's too controversial.
• When multiple callbacks exist, do we skip the rest of the chain if one returns the shortcut? I assume we do as it is customary to do so...so I've also chosen that path in my branch (both for before and after controller hooks)
• Do we always "skip" the after callbacks if the result from before callbacks shortcuts it? I assume we do, as it is the safest thing to do?...although we might want to think of a flag or a way to indicate that a given callback should always be executed for that stage (i.e. an "ensure" type thing) so that it might be easier to implement "around" filters (or something more similar to the way Rack injects the calls). Again I've implemented this simple and common approach of skipping the rest in the branch for now.

So, can you give that branch a try and see if that suits your needs?

As far as how you want to approach your auth, I think that you should hook into the before :action filter rather than the after :validation one, and make sure your filter returns a Praxis::Responses::Unauthorized.new object from it. I.e. something like this:

  before :action do |controller|
    if controller.request.headers.AUTH_TOKEN
      Praxis::Responses::Unauthorized.new unless controller.current_user
    end
  end

[jasonayre]

Just dropped in the branch to give it a whirl, as far as I can tell it looks great! Thanks so much.

Regarding bullet point 3:

I might have a use case against it:

Right now Im actually having an issue with active record not recycling db connections, which may prove as a potential use case for ^. Im thinking that in an ideal api world, what would happen is (and this may be the totally wrong solution to the problem, but for the sake of example):

Request comes in, check if auth header present
If no auth header, dont attempt to checkout a connection from the pool, we know its bad, dont bother checking out a connection

if auth header, wrap the action (and only the action part of the request) itself in an around filter, to wrap the action in a checked out active record connection -- (I believe, rails basically wraps entire request, or most of, in a checked out active record connection?), so at end of the around filter, the connection gets checked back into the pool. That, SEEMS, to make the most sense to me, but it may be a terrible idea, Im not sure.

I guess my thought is, this way, the connection is only being used when absolutely necessary, which == more efficient use of resources/connections, and gets returned to the pool faster? Which, in theory Id think would be nice because at the end of the response lifecycle, you may be doing things like connecting to a honeybadger or whatever service to report errors, or logging, and if that hangs, then your db connection could get tied up as well, etc etc.

ANYWAYS, once again, it may be the wrong solution :) . But if it is a valid use case, it would seem that around filters on a per request stage basis would be necessary for me to achieve that, which would rely on continued execution of the after filters, or at least an option to pass in when defining the filter to indicate not to short circuit the around filters.

What do you think?

[blanquer]

Jason, I just pushed a bunch more things, and fixes, including an initial prototype for a simple around filter (using a block construct).

I've actually merged it all to master, so we (and you) can play with it while discussing if that would be good enough for the around filters.
So, point back to master, and give it a whirl...and see if you can manage everything you wanted with your connection pool. You can see the gist of the around filters looking at an example [here](https://github.com/rightscale/praxis/blob/master/spec/spec_app/app/controllers/instances.rb#L22-L36_