Hi everyone, I don't to sound pedantic here, but can we be sure to distinguish between Authentication (auth), Authorization (authz), and Access Control? See the intro of this section of the Apache manual:
http://httpd.apache.org/docs/1.3/howto/auth.html#intro Just to be clear, this looks to be a problem entirely of authorization and not authentication or access control. Take a look at Radiant's login system in lib/login_system.rb: Auth is provided by the before_filter #authenticate (which unfortunately also authorizes to some extent), which calls #current_user. I'd recommend using this method instead of calling User.find(session[:id]) manually. This way your extension will work with other extensions that may overload the authentication mechanism (e.g. I'm working on an extension that uses RubyCAS-Client [1] to allow centralized authentication over multiple applications -- and I'm going to do this by overriding #current_user). Ok, so let's consider an authz system: let's say a user has roles. Roles grant them permission. Roles can either be global "Uber-administrator" or granular to a page "Editor of the lunch menu web page". Right now Radiant determines if the user is authorized using the #user_has_role?(action). If you overrode this to call to include a page parameter, it would probably do what you need. E.g. def user_has_role?(role, page) current_user.send("#{role}?", page) end Also override #user_has_access_to_action? so that it include the page param. So then you just need to monkey-patch User so that messages like "current_user.uber_admin?(page_doesnt_matter_because_im_uber)" or "current_user.lunch_menu_editor?(lunch_menu_page)" make sense. I flirted with added an authz system to Radiant awhile back, and while this project [2] seems to be dormant and permissions are in funky little strings, the data model is solid and is what I'd recommend for the storing users and roles. Well, I hope this helps. Auth and authz can be tricky, so I wish you the best of luck. I think the hardest part really, is putting together a role admin interface that makes sense. That's why I'm leaving that as an exercise to you... ;) -Andrew [1] For more on RubyCAS, see: http://rubyconf2007.confreaks.com/d3t2p1_security_and_identity.html http://code.google.com/p/rubycas-server/ http://code.google.com/p/rubycas-client/ [2] http://www.writertopia.com/developers/authorization On Dec 21, 2007 6:25 PM, Greg <[EMAIL PROTECTED]> wrote: > So, here is the jist of the brainstorm, with some almost code... what > do ya'll think? > > Radiant ACL proposal (very rough!) > > Step #1 Deal with Caching > > Inject a method into show_page to call the authentication system. We > need to know what page is being rendered so that we can pull group > information. I propose passing the page as to the show page module to > facilitate this. At first, I would suggest that this only applies to > the admin pages. It would be pretty easy to allow pluggable user > modules to overwrite the base one, and you could add granular rights > to any page. > > In our environment, even with small teams, there are certain pages > that only the leadership portion of the team should be able to view. > > > def show_page(page) > if authenticator(page.find.groups(:all)) > render_page > else > render_login_error_page > end > end > > def render_page > response.headers.delete('Cache-Control') > url = params[:url].to_s > if (request.get? || request.head?) and live? and > (@cache.response_cached?(url)) > @cache.update_response(url, response, request) > @performed_render = true > else > show_uncached_page(url) > end > end > > Step 2 - Validate Access > > The authenticator would look something like this: > > def authenticator(groups) > unless session[:id].nil? > user = User.find(session[:id]) > effective_groups = user.find.groups & groups > for group in effective_groups > case group.rights > when 0 #denied access > redirect_to_login and return false > when 1 #read only > return true > when 2 #read and write > #some action to allow folks to edit > when 3 #read, write and grant > #some action to allow folks to edit, and add people to the ACL > end > else > if groups.include?(anon_group_id) > return true > else > return false > end > end > end > > > > > On Dec 21, 2007 7:37 AM, Greg <[EMAIL PROTECTED]> wrote: > > I am planning on putting a few hours into playing with this today - I > > will post my outcomes. > > > > > > On Dec 21, 2007 1:47 AM, Aitor Garay-Romero <[EMAIL PROTECTED]> wrote: > > > Currently there is no ACL support in Radiant. This has been proposed > > > and > > > discussed in this list, search the archives. > > > > > > I have been brainstorming about this lately and i have some ideas for > > > working in a "security extension" in the future. I have done some UML > > > diagrams and pen-on-paper mocks of a possible UI, but nothing tangible > > > yet. > > > Maybe in the next wave of energy+motivation... > > > > > > /AITOR > > > > > > > > > On Dec 19, 2007 6:00 PM, Rick Henderson <[EMAIL PROTECTED]> wrote: > > > > > > > Greetings all, > > > > > > > > New to Radiant and the community, but my hope is that my co-worker and > > > > I > > > > can contribute a lot to the project in the years to come. > > > > > > > > That being said, our first step is to develop a user extension for > > > > Radiant. We need the ability to add users and group security to our > > > > site > > > > pages. > > > > > > > > Has this been proposed, or worked on, yet? Are their any "hooks" in > > > > the > > > > code for doing this that we can leverage in making this extension? > > > > > > > > If there is no pre-positioned ability for this we thought about > > > > handling > > > > this through the use of a tag perhaps and then utilizing the inheritance > > > > of > > > > Radiant to pass down the security in the sections required. > > > > > > > > In closing, I just have to say that I love the simplicity and power of > > > > how > > > > Radiant is designed. It's organization allows for a very flexible > > > > system > > > > to > > > > be developed. > > > > > > > > Thanks for the hard work so far on this great project! > > > > > > > > - Mystic > > > > _______________________________________________ > > > > Radiant mailing list > > > > Post: [email protected] > > > > Search: http://radiantcms.org/mailing-list/search/ > > > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > > > > > > _______________________________________________ > > > Radiant mailing list > > > Post: [email protected] > > > Search: http://radiantcms.org/mailing-list/search/ > > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > > > > > > > > > > -- > > Da Dukk, on the road again! > > http://www.NWGamers.org - for a good time! > > http://greg.nokes.name Ramblings from the Roost - For a Bad Time! > > > > > > -- > Da Dukk, on the road again! > http://www.NWGamers.org - for a good time! > http://greg.nokes.name Ramblings from the Roost - For a Bad Time! > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
