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