authentication and authorization
William Ross
First I should start by saying what a pleasure it was to throw away
my ten-year old mod_perl-based cms and start using radiant instead. A
little painful at the time, but a huge relief, and now it's three
months later I'm never going back.
So thank you.
There are a few things I miss, of course, and over the next couple of
months I'll probably need to add some of them back in. As per the
instructions on the wiki, I thought I'd better mention them here
first in case people are already at work.
(Also, is it completely futile to develop plugins or add code while
the new plugin system is in the works, and if so, do we have any idea
of when it might be released?)
my to-do list begins with these two:
* authentication and authorization
I need to be able to do proper user & group access-management where
certain groups have access to certain pages. This will need to apply
both to the published and the administrative views, so that editorial
and access rights are controlled through the same interface. The code
for this is fairly easily borrowed - it's not like it's a new problem
- so it's only a question of where to put it. It's quite urgent for
me, too, and I'll probably have to work on it this week. I already
miss the way mod_perl let's you drop a few lines of code into the
Authz phase of the apache lifecycle :(
I've tried the password-protected behaviour, btw, but I don't really
want to use basic auth and would rather store the users in the database.
* asset management
I will need some simple integrated image control. I notice that
mephisto's system has been mentioned positively here, and while I
agree that its clarity is very impressive I think a radiant
equivalent could also use a bit more integration. Any part should be
able to have one or more images, and the template should be able to
specify dimensions and layout on the fly. This too is fairly easily
coded but a bit fiddly and would involve a dependency on RMagick that
you might not want.
Please let me know if anyone is working in these areas, if you have
any suggestions, or if it would be silly to do this work at the moment.
thanks,
will
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:01 -0500 2007
Originally sent on Mon Oct 16 04:36:02 -0400 2006
William Ross
I've been going through radiant working out where to add
authentication and authorization checks (I need proper user and group
management and group-based access and authoring permissions). I've
got three choices, I think, but if anyone would like to suggest more
or disagree with the options I'd be very glad to hear it:
* Create an 'authorized' behavior based on M@ McCray's password-
protected that will check group membership and permission against a
couple of new database tables
* Create a behavior that bolts on one of the standard rails login
gems (eg salted hash)
* Extend the existing radiant user-management
I'm inclined to work on radiant itself, partly because there's a
perfectly good login mechanism there already, and partly because the
plugin system is in an in-between state and I can't tell when RPS2 is
going to be ready for use. This would mean (thinking out loud):
* remove roles ie (admin and developer columns) from user table
* create a groups table (each with welcome page url)
* create a roles table, or perhaps just move admin and developer
flags to groups table
* user habtm groups
* page habtm groups (defaults to open but inherits restrictions)
* user.admin? and user.developer? methods to simplify code changes
* add 'users & groups' tab to management interface
* create simple forms for drag and drop management of groups and roles
* add access control to page-editing form
So there are a few obvious questions:
* Does this sound like something you would be prepared to add to
radiant core, or is it too much clutter?
* Is there any other work happening in this area?
* Are there other roles that you're already thinking of adding?
I'll probably have to do this in a quick and hacky way to begin with,
then tidy it up and make it respectable afterwards. Any advice would
be most welcome.
thanks,
will
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Wed Oct 25 09:49:18 -0400 2006
John W. Long
> * Does this sound like something you would be prepared to add to
> radiant core, or is it too much clutter?
I don't presently have plans to make this a core component. However, I
could see something like this working as a plugin.
> * Is there any other work happening in this area?
Not at the moment. If you wanted to create a patch for starters I would
definitely be interested in seeing what you come up with. My concern is
that a full users/groups permissions system is too complex for the core.
I'm open to ideas for making the plugin system flexible enough to
support this.
> * Are there other roles that you're already thinking of adding?
Publisher, Editor, and Writer.
--
John Long
http://wiseheartdesign.com
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Wed Oct 25 12:09:54 -0400 2006
William Ross
On 25 Oct 2006, at 17:09, John W. Long wrote:
> William Ross wrote:
>> * Does this sound like something you would be prepared to add to
>> radiant core, or is it too much clutter?
>
> I don't presently have plans to make this a core component. However, I
> could see something like this working as a plugin.
>
>> * Is there any other work happening in this area?
>
> Not at the moment. If you wanted to create a patch for starters I
> would
> definitely be interested in seeing what you come up with.
Will do.
> My concern is
> that a full users/groups permissions system is too complex for the
> core.
> I'm open to ideas for making the plugin system flexible enough to
> support this.
It's actually very simple, as it turns out. All I'm really doing is
adding a 'group' model and changing the User.admin? and
User.developer? methods to look for groups with those flags instead.
Your nice dry controller setup has made the rest very easy.
I'll look through the new plugin code and see if I can come up with a
sensible suggestion.
One question: I'm just starting the interface work, and getting a
real headache trying to work out at what point values like
page_index_url are defined. I can see how it would work in the
model_controller, I just can't see where the call happens. I guess
it's somewhere in inheritable_class_attributes? meh.
thanks,
will
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Wed Oct 25 12:25:04 -0400 2006
Jamie Wilkinson
>>> * Does this sound like something you would be prepared to add to
>>> radiant core, or is it too much clutter?
>>
>> I don't presently have plans to make this a core component.
>> However, I
>> could see something like this working as a plugin.
>>
I've been pondering going about doing exactly this same thing for a
while now and would love to see this added in -- it feels like
something that would need to be in core, unless APS2 allows plugins
to interfere w/ the normal admin interface's rendering pipeline. i.e.
to accommodate for things like setting a top level page for a user, a
great hack I'm using extensively(1)
My sticky-note jotted plan involved users, groups, and roles, and
then a permissions table habtm to all 3 that used "controller.method"
level access, with a helper that would let you invent a few extras
for things like "can i edit other people's articles? can i change the
status of my articles to 'published'? can i change status of other
people's articles? what is my top-level page?" This is all paragraph
pseudo-code, but I'm more than happy to help! :)
-jamie
(1) <http://dev.radiantcms.org/radiant/wiki/
HowToSetATopLevelPageForUser>, much thanks to mhill at lighthouse.org
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Wed Oct 25 22:27:02 -0400 2006
Bodhi
>>> William Ross wrote:
>>>> * Does this sound like something you would be prepared to add to
>>>> radiant core, or is it too much clutter?
>>>
>>> I don't presently have plans to make this a core component.
>>> However, I
>>> could see something like this working as a plugin.
>>>
>
> I've been pondering going about doing exactly this same thing for a
> while now and would love to see this added in -- it feels like
> something that would need to be in core, unless APS2 allows plugins
> to interfere w/ the normal admin interface's rendering pipeline. i.e.
> to accommodate for things like setting a top level page for a user, a
> great hack I'm using extensively(1)
>
> My sticky-note jotted plan involved users, groups, and roles, and
> then a permissions table habtm to all 3 that used "controller.method"
> level access, with a helper that would let you invent a few extras
> for things like "can i edit other people's articles? can i change the
> status of my articles to 'published'? can i change status of other
> people's articles? what is my top-level page?" This is all paragraph
> pseudo-code, but I'm more than happy to help! :)
One question, what do groups give you that adding a couple more roles
doesn't? Now radiant has 'normal', 'admin' and 'developer' roles, so
why couldn't it simply be extended a bit to provide 'publisher' and
'editor' roles? (I'd be happy to be shown why, I just haven't seen
the reason yet, or I missed it.)
Bodhi
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Wed Oct 25 22:42:00 -0400 2006
William Ross
On 26 Oct 2006, at 03:42, Bodhi wrote:
> On 26/10/2006, at 11:27 AM, Jamie Wilkinson wrote:
>
> <snip>
> One question, what do groups give you that adding a couple more roles
> doesn't? Now radiant has 'normal', 'admin' and 'developer' roles, so
> why couldn't it simply be extended a bit to provide 'publisher' and
> 'editor' roles? (I'd be happy to be shown why, I just haven't seen
> the reason yet, or I missed it.)
My users need to add groups and manage their permissions.
I've been lazy with the roles, though, and just added 'admin',
'developer' and 'editor' flags to the groups table. A proper roles
table would be more versatile but for it to be useful I think you'd
also need to make the permissions system more fine-grained (can-edit-
pages, can-create-snippets, can-delete-layouts, etc). I'm also
avoiding the 'publisher' role for now because for that you'd need to
make the pages and page parts tables versioned, or find some other
way to hold the approved and edited versions of the same page-with-
parts at the same time.
best,
will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant-core/attachments/20061026/8fb6a427/attachment.htm
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Thu Oct 26 05:46:38 -0400 2006
Jamie Wilkinson
> doesn't? Now radiant has 'normal', 'admin' and 'developer' roles, so
> why couldn't it simply be extended a bit to provide 'publisher' and
> 'editor' roles? (I'd be happy to be shown why, I just haven't seen
> the reason yet, or I missed it.)
You know, I've been stewing on this one for a few days, and the only
real argument I could come up with for groups was clustering of top-
level pages, which could be easily accomplished with "duplicate"
roles (e.g. "Editor, R&D" vs. "Editor, Production")
So I may scrap my groups tables and just focus on users and roles
unless something compelling comes along :)
-jamie
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Fri Oct 27 17:35:20 -0400 2006
Chris Garrett
consulting project I am working on. For purely pragmatic get-it-done
reasons, I am just taking the existing Radiant code base and inserting this
functionality, with the goal of pulling it out later as a plug-in after this
engagement. In my case I am implementing user/role/permissions. I will be
more than happy to share the code when it is completed.
I am doing the same thing with a file resource manager (e.g. downloadable
files, inserting images). Again, I will share this code if anyone is
interested.
This project is scheduled to be complete in about a month, so I will share
the results at that time.
Chris Garrett
On 10/25/06, Jamie Wilkinson <jamie at tramchase.com> wrote:
>
> >> William Ross wrote:
> >>> * Does this sound like something you would be prepared to add to
> >>> radiant core, or is it too much clutter?
> >>
> >> I don't presently have plans to make this a core component.
> >> However, I
> >> could see something like this working as a plugin.
> >>
>
> I've been pondering going about doing exactly this same thing for a
> while now and would love to see this added in -- it feels like
> something that would need to be in core, unless APS2 allows plugins
> to interfere w/ the normal admin interface's rendering pipeline. i.e.
> to accommodate for things like setting a top level page for a user, a
> great hack I'm using extensively(1)
>
> My sticky-note jotted plan involved users, groups, and roles, and
> then a permissions table habtm to all 3 that used "controller.method"
> level access, with a helper that would let you invent a few extras
> for things like "can i edit other people's articles? can i change the
> status of my articles to 'published'? can i change status of other
> people's articles? what is my top-level page?" This is all paragraph
> pseudo-code, but I'm more than happy to help! :)
>
> -jamie
>
>
> (1) <http://dev.radiantcms.org/radiant/wiki/
> HowToSetATopLevelPageForUser>, much thanks to mhill at lighthouse.org
> _______________________________________________
> Radiant-Core mailing list
> Post: Radiant-Core at lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant-core/attachments/20061030/50ef3f7d/attachment.htm
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Mon Oct 30 09:11:18 -0500 2006
William Ross
> I am beyond the pondering stage on this, and have begun
> implementation for a consulting project I am working on. For
> purely pragmatic get-it-done reasons, I am just taking the existing
> Radiant code base and inserting this functionality, with the goal
> of pulling it out later as a plug-in after this engagement. In my
> case I am implementing user/role/permissions. I will be more than
> happy to share the code when it is completed.
I've done user/group/read/write control, with the existing role flags
attached to groups instead and a new 'editor' role to signify global
page-editing permission. Like you I've done it for immediate use with
one eye on packaging it after that. Perhaps I should put up a rough
demo-and-patch sooner so that we can compare notes? It's definitely
not a plugin, though.
> I am doing the same thing with a file resource manager (e.g.
> downloadable files, inserting images). Again, I will share this
> code if anyone is interested.
very interested. yes please.
As it happens, I've also needed downloads, but given page-access
control I'm implementing it more simply as a download-conduit
behavior so that the (limited access) page can serve files from a
particular directory outside the public site. I may also add a photo-
gallery behavior, so it sounds like our requirements are very similar.
> This project is scheduled to be complete in about a month, so I
> will share the results at that time.
Mine is live now, but it'll be a week or so before I can really
present it properly for reuse.
best,
will
Spanner Ltd
18 Fountain Street
Ulverston
Cumbria LA12 7EQ
01229 588098
www.spanner.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant-core/attachments/20061031/413ecd4d/attachment.htm
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Mon Oct 30 19:36:58 -0500 2006
Jamie Wilkinson
>> implementation for a consulting project I am working on. For
>> purely pragmatic get-it-done reasons, I am just taking the
>> existing Radiant code base and inserting this functionality, with
>> the goal of pulling it out later as a plug-in after this
>> engagement. In my case I am implementing user/role/permissions.
>> I will be more than happy to share the code when it is completed.
Would love to be a part of this branch as I'm also in need of these
features over the next few months
> As it happens, I've also needed downloads, but given page-access
> control I'm implementing it more simply as a download-conduit
> behavior so that the (limited access) page can serve files from a
> particular directory outside the public site. I may also add a
> photo-gallery behavior, so it sounds like our requirements are very
> similar.
Have you seen the page_part_types patch(1), the (very rough) multiple
upload page_part_type(2), and the existing gallery behavior(3) ?
-jamie
(1) <http://dev.radiantcms.org/radiant/ticket/147>
(2) <http://www.mail-archive.com/radiant at lists.radiantcms.org/
msg00972.html>
(3) <http://nobits.org/svn/rails/plugins/gallery_behavior/>
P.S. I can't wait to start officially talking about page types
instead of behaviors :)
____________________________________________________________________
Imported from the old mailing list on Tue Mar 06 13:42:02 -0500 2007
Originally sent on Tue Oct 31 00:11:07 -0500 2006