I have to somewhat agree with Paul. Setting the permissions for the system is the developers jobb not the admins. The admins handles the users and adds them to the correct groups depending on what their permissions should be.
On 3/31/06, Kevin Horn <[EMAIL PROTECTED]> wrote: > I've seen mentioned several times on this list that an eventual goal of the > identity system in TurboGears is to be able to specify the required groups, > permissions, etc. for access to a resource in a config file. This would > allow an administrator, rather than a developer, to set security policy. I > have not seen any ideas on how this would actually work, though. Is anyone > actively working on this? In case the answer is no, here are some ideas > that I just had... > > DISCLAIMER: I have not even looked at the code for the @identity decorator > and have no idea if the following would work, much less whether it's > practical to implement, or even a good idea. If I'm totally off base on > this, please just let me know. I won't take offense :) > > So I was looking at the examples over in the wiki > (http://trac.turbogears.org/turbogears/wiki/IdentityManagement) > and I noticed that the @ identity.require() decorator can take not only > parameters (like @identity.require(group="admin") ), but also callables > (like @identity.require( identity.in_group( "admin" ) ) ). [I am presuming > that this is still the case...that article looks like it is in a state of > flux.] If this is the case, then would it be possible to have a callable > that can be passed to the decorator which would direct the decorator to use > a config file? > > Something like: > @identity.require( identity.check_config_file( "identity.cfg" )) > > The decorator could then check the config file for the appropriate > authorization information. The config file could maybe look something like > this: > > [resource_name] > in_group = "admin" > has_permission = "edit" > > ...or something of the sort. > > AND and OR type authorization could possibly be handled by using AND/OR in > the string value for the config option, like: > > [resource_name] > in_group = "admin OR superuser" > has_permission = "edit" > > Like I said earlier, I haven't delved into the inner workings of the > identity system, but it seems that, at least for the user (TG app developer) > this would allow the use of a config file for authorization data without > having to relearn a whole new system. > > Potential problems/limitations: > - I have no idea how hard/easy this would be to implement > - Performance could be a problem > - Might run into problems with applying one set of auth info to an entire > controller > - The example config syntax I have suggested above is quite simplistic, and > might not be able to cover all use cases. A better one probably > could/should be devised. > - Config file could get awfully verbose > - AND/OR could be tricky across auth types...for example, how would say > "authorize if the user is an admin OR has the edit permission" > > Anyways, this is just an inkling of an idea, and I haven't put more than 10 > minutes thought into it. I'm hoping though, that it will prompt a > discussion among the really smart people around here, so that they can come > up with a better idea than I can. :) > > Of course, it's completely possible that someone out there already has a > better idea and will commit it to the repository any minute now... > > Please share your thoughts... > > > > -- cheers elvelind grandin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
