Masterview devel - Feb 2007 - More explanation of how admin page custom authorization works

Just to explain what I currently have in place in the trunk.

I have moved the check_authorization method out of the masterview_controller
and put it in a mixin.

Additionally I setup a config.admin_auth_mixin accessor which defaults to
nil but if set to a hash can be used to set the mixin and method to use
instead of our default auth method (which currently just checks if
local_request?)

I also created an example of an authorization mixin and put it in
examples/rails_app_admin_auth/auth_local_request_mixin.rb which does the
same was what we do now. I figured we can create other examples of other
mechanisms in this folder later.

The configuration goes like this

config.admin_auth_mixin = { :file => ''lib/whatever'',
:module =>
:MyAuthModule, :method => :check_authorization }

These are each optional, for instance if you provide file, then it will
require this path (assuming relative to RAILS_ROOT). If you provide module
name (string or symbol) then it will include this into Masterview
controller. If you specify method name then it will use this for the
before_filter call (defaulting to check_authorization if not provided).

Let me know what you think.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20070207/9e4e9735/attachment.html

> > I have moved the check_authorization method out of the
masterview_controller and put it in a mixin.
 
Wrong granularity, I think.  The method that should be pluggable via the
mixin is *only* the allow_access? predicate, not the referencing
check_authorization method of the admin controller.  Factoring the latter
involves the client inappropriately in the operation of the admin
controller, which shows up in the more complicated way you had to rewrite
the before_filter spec in MasterviewController.  I think it''s not the
client''s business to have anything to say about what happens if access
is
not allowed (the redirect) - that''s the controller''s business.

So I think the original check_authorization should be put back into
MasterviewController and the mixin is responsible for supplying the
allow_access? predicate.  I don''t think it''s necessary to
allow plugins to
change this method name - if you want to customize the access checking,
provide a module which implements an allow_access? method which is mixed
into the controller (and thus can assume it is invoked in an
ApplicationController instance)

Other observation is that the logic for actually doing the mixing-in is
rather messy to have in MasterViewController itself.  Would rather have that
done as part of MV init, though I think we can''t just put into
init_mv_admin_pages as I''d wish because of load order/startup timing
issues
[expect that''s why you''ve got what you''ve got].  But
even given that I''d
prefer to have some one-liner spec in MasterviewController for the actual
mixing-in step.

I think the solution is to push logic back into MV init which actually
decides what file to require and does so and which records a value which can
be accessed from the MasterView module (?constant or addition the recorded
configuration?) which is the mixin module itself.  Then

class MasterviewController < ApplicationController
  include MasterView::MIO::DefaultGenerateMIOFilter
  include MasterView::ADMIN_AUTH_MIXIN  # or whereever we record the actual
module
  #assert we now have an instance method named :allow_access? defined
  before_filter :check_authorization, :except => [ :access_not_allowed ]
...
end

~ Deb 

#-----------------------------------------------------------------
#ORIGINAL IMPL WAS:
#-----------------------------------------------------------------

  # Default implementation of authorization check
  # to restrict access to administrative services
  def allow_access?
    # a more general solution might look something like:
    # current_user && user_has_perm?(''mv-admin'')
    # backstop: only allow for developer testing on local machine
    local_request?
  end

  # Check that the current user has authorization to access admin operations
  def check_authorization
    if ! allow_access?
      redirect_to :action => :access_not_allowed
    end
  end
#-----------------------------------------------------------------