Masterview devel - Jan 2007 - I added config.admin_check_auth_proc to allow configurable authorization for MasterView admin pages

I added a configuration option to allow changing the proc used for
checking authorization for MasterView admin controller pages.

config.admin_check_auth_proc defaults to

lambda { |controller_instance| controller_instance.local_request? }

which restricts to local requests.

This can be overriden to a different block to check user permissions
or other things.

This is currently checked into the trunk.


-- 
Jeff Barczewski, MasterView project founder
Inspired Horizons Ruby on Rails Training and Consultancy
Next Ruby on Rails plus JRuby workshop Feb 22-24 St. Louis, MO
http://inspiredhorizons.com/training/rails
Limited seating, register now!

weeeeelllll.... I don''t like it.

The awkwardness you ran into even with the simple local_request? predicate
may well recur on user-supplied impl''s as well; having to write
"controller.send :foo" is just unnatural.

I expect to hook up authentication and authorization mechanisms in my sites
very soon which have a user model, where logged in user is marked in
session, and a roles/permissions mechanism for expressing the rights granted
to a user.  So the check I''m going to want to write is essentially the
predicate "is there a logged-in user and do their perms include admin
rights?"

And I don''t know whether I''d necessarily declare those as
public methods
(have to think about that, anyway, but don''t know that it''s a
good
assumption that people necessarily would)

Don''t want to have to write tricky/slimy block code which has to poke
at its
controller arg using send to get around protected access.  (and you flat
can''t get at private, I think - tho I avoid those)

Allowing developer to plug in this access check functionality as a mixin
might be a better approach.  Allows you to write the code in a fairly
natural style.  Then we break our default impl out into the default mixin
impl; ref to that class is the default value of the admin_check_auth config
setting (name appropriately...).  App developer can set the config option
with the name of their version of the auth check mixin class.  Initializer
is responsible for installing when activating the admin controller feature.

Something like that, anyway, perhaps some mildly tricky details to work out
to get this running.  But something like this might be better than using a
block if access control is going to get in the way.

~ Deb 

  # Default implementation of authorization check
  # to restrict access to administrative services
  def allow_access?
    # backstop: only allow for developer testing on local machine
    local_request?
  end

  # authorization check to restrict access to administrative services
  # (app-specific implementation)
  def allow_access?
    current_user && user_has_perm?(:admin)
  end

-----Original Message-----
From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Sunday, January 21, 2007 9:03 PM
To: masterview-devel at rubyforge.org
Subject: [Masterview-devel] I added config.admin_check_auth_proc to
allowconfigurable authorization for MasterView admin pages

I added a configuration option to allow changing the proc used for checking
authorization for MasterView admin controller pages.

config.admin_check_auth_proc defaults to

lambda { |controller_instance| controller_instance.local_request? }

which restricts to local requests.

This can be overriden to a different block to check user permissions or
other things.

This is currently checked into the trunk.


--
Jeff Barczewski, MasterView project founder Inspired Horizons Ruby on Rails
Training and Consultancy Next Ruby on Rails plus JRuby workshop Feb 22-24
St. Louis, MO http://inspiredhorizons.com/training/rails
Limited seating, register now!
_______________________________________________
Masterview-devel mailing list
Masterview-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/masterview-devel

I''m thinking possibly we could just substitute the code in for the
local_request anyway into our default check. Then we wouldn''t have to
call
any private methods and in case they change things we won''t break since
they
can change private methods at any time. We can just put that line of code in
our default check.

However it is always safer to not make controller methods public unless you
want Rails to expose them, because people can type in the appropriate url
and usually invoke them directly. So everything that is not supposed to be
exposed needs to be protected or private. (Actually I think current version
of send can get at any method, though they are changing this in Ruby 2 and
you have to use some other method)

All that being said, I am fine with doing something else like a mixin
assuming it won''t have issues where it can be called from Rails. There
might
be an additional way to protect what methods rails exposes.

Do you think we should try to get a release up that fixes the issues with
Rails 1.2 quickly (maybe even backing out this auth change) and then follow
up with these other changes?

The not being able to debug compile errors is one thing I want to get out to
users as soon as possible so that any new users who download the gem and try
it with Rails 1.2 don''t have a blank screen when they hit a compile
error
(misspelling something). It is fixed in trunk.

So let me know what you think regarding what we have on the table. I
haven''t
yet made the changes to link_to either.

Jeff

On 1/28/07, Deb Lewis <djlewis at acm.org> wrote:
>
> weeeeelllll.... I don''t like it.
>
> The awkwardness you ran into even with the simple local_request? predicate
> may well recur on user-supplied impl''s as well; having to write
> "controller.send :foo" is just unnatural.
>
> I expect to hook up authentication and authorization mechanisms in my
> sites
> very soon which have a user model, where logged in user is marked in
> session, and a roles/permissions mechanism for expressing the rights
> granted
> to a user.  So the check I''m going to want to write is essentially
the
> predicate "is there a logged-in user and do their perms include admin
> rights?"
>
> And I don''t know whether I''d necessarily declare those as
public methods
> (have to think about that, anyway, but don''t know that
it''s a good
> assumption that people necessarily would)
>
> Don''t want to have to write tricky/slimy block code which has to
poke at
> its
> controller arg using send to get around protected access.  (and you flat
> can''t get at private, I think - tho I avoid those)
>
> Allowing developer to plug in this access check functionality as a mixin
> might be a better approach.  Allows you to write the code in a fairly
> natural style.  Then we break our default impl out into the default mixin
> impl; ref to that class is the default value of the admin_check_auth
> config
> setting (name appropriately...).  App developer can set the config option
> with the name of their version of the auth check mixin class.  Initializer
> is responsible for installing when activating the admin controller
> feature.
>
> Something like that, anyway, perhaps some mildly tricky details to work
> out
> to get this running.  But something like this might be better than using a
> block if access control is going to get in the way.
>
> ~ Deb
>
>   # Default implementation of authorization check
>   # to restrict access to administrative services
>   def allow_access?
>     # backstop: only allow for developer testing on local machine
>     local_request?
>   end
>
>   # authorization check to restrict access to administrative services
>   # (app-specific implementation)
>   def allow_access?
>     current_user && user_has_perm?(:admin)
>   end
>
> -----Original Message-----
> From: masterview-devel-bounces at rubyforge.org
> [mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff
> Barczewski
> Sent: Sunday, January 21, 2007 9:03 PM
> To: masterview-devel at rubyforge.org
> Subject: [Masterview-devel] I added config.admin_check_auth_proc to
> allowconfigurable authorization for MasterView admin pages
>
> I added a configuration option to allow changing the proc used for
> checking
> authorization for MasterView admin controller pages.
>
> config.admin_check_auth_proc defaults to
>
> lambda { |controller_instance| controller_instance.local_request? }
>
> which restricts to local requests.
>
> This can be overriden to a different block to check user permissions or
> other things.
>
> This is currently checked into the trunk.
>
>
> --
> Jeff Barczewski, MasterView project founder Inspired Horizons Ruby on
> Rails
> Training and Consultancy Next Ruby on Rails plus JRuby workshop Feb 22-24
> St. Louis, MO http://inspiredhorizons.com/training/rails
> Limited seating, register now!
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>


-- 
Jeff Barczewski, MasterView core team
Inspired Horizons Ruby on Rails Training and Consultancy
Next Ruby on Rails plus JRuby workshop Feb 22-24 St. Louis, MO
http://inspiredhorizons.com/training/rails/index.html
Limited seating, register now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20070129/f6878ad9/attachment-0001.html

not sure how fast people are switching to 1.2, but certainly blank screen on
compile error would be good to fix!
 
I think we should back out the access check change if we want to get a
release out for other reasons; I think we shouldn''t change that until
we
think we''ve got the right solution.  Would rather document workaround
in the
meantime if necessary.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20070129/ef9a8205/attachment.html