Opened 16 years ago
Last modified 8 years ago
#7650 new enhancement
authz_policy.py - Support Trac groups
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | unscheduled |
Component: | general | Version: | 0.12dev |
Severity: | normal | Keywords: | authzpolicy groups |
Cc: | leho@…, mmitar@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The plugin doesn't support Trac groups (under Admin/Permissions there is an option "Add Subject to Group") and it is a little strange that you need to define groups in a special file.
Therefore I made a patch against source:/trunk/sample-plugins/permissions/authz_policy.py@7457 that adds this functionality in a little ugly way. It could be done better, therefore this comment. You can obtain it on http://gw.tnode.com/0149-TracDevelopment/.
Attachments (0)
Change History (12)
comment:1 by , 16 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Keywords: | authz groups added |
---|---|
Resolution: | duplicate |
Status: | closed → reopened |
This is not a duplicate; it points at a totally different issue.
The authz_policy config file defines groups. Trac also defines groups. These groups are not related in any way. It is perfectly possible to have a group "administrators" in Trac which contains John and Jack, and define a group "administrators" in the authz_policy configfile which contains Joe, and not John or Jack. This also means that the only way to edit the fine grained permissions, seems to be logging in to the shell and manually editing the authz_policy configfile. Great fun if you want to do fine grained permissions on a wiki.
This functionality could be improved *bigtime* if authz_policy would actually support Trac groups, instead of keeping its own set of shadow groups that are not managed by any of the web admin tools.
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
I made the following changes to authz_policy.py:
223 def authz_permissions(self, resource_key, username): 224 if username and username != 'anonymous': 225 valid_users = ['*', 'authenticated', username] 226 db = self.env.get_db_cnx() 227 cursor = db.cursor() 228 cursor.execute("SELECT action FROM permission WHERE username='%s'" % username) 229 rows = cursor.fetchall() 230 for action in rows: 231 if not action[0].isupper(): 232 valid_users += [action[0]]; 233 else: 234 valid_users = ['*', 'anonymous'] 235 self.log.debug('Valid users and groups for %s: %s', username, ','.join(valid_users)) 236 for resource_section in self.authz.sections: 237 resource_glob = to_unicode(resource_section) 238 if '@' not in resource_glob: 239 resource_glob += '@*' 240 if fnmatch(resource_key, resource_glob): 241 section = self.authz[resource_section] 242 for who, permissions in section.iteritems(): 243 if who in valid_users: 244 self.log.debug('%s matched section %s for user %s', resource_key, resource_glob, username) 245 if isinstance(permissions, basestring): 246 return [permissions] 247 else: 248 return permissions 249 else: 250 self.log.debug('%s does not match any of valid_users: %s', who, valid_users) 251 return None
It does what I want - I still have to edit the authz policy file to get ACLs set on specific wiki pages (this could probably be done using a plugin in the web admin) but once the ACLs have been set, all permissions are set using the standard Trac groups. Do note that this will no longer process the internal authz groups as they might conflict with the builtin groups. I don't consider this an issue but it's worth mentioning with big bold red letters.
Later on, it might be handy to get rid of the authz file altogether and just use a small DB table to collect ACLs. I have a feeling this is beyond my capabilities though. :-)
comment:6 by , 14 years ago
Cc: | added |
---|
follow-up: 8 comment:7 by , 14 years ago
Lennart, your patch is really ugly and even more hackish. First of all it contains SQL code and can't resolve groups as members of groups and doesn't support other authentication backends, second it is a little inefficient (upper case filtering can also be done inside SQL) and the biggest problem is that it contains a possible security hole (I hope you have heard of SQL injections, therefore don't build strings with SQL code in a brain damaged PHP-like way)!
Anyway, an improved and correctly working version of my initial patch can be found on http://gw.tnode.com/0149-TracDevelopment/. It also works with different authentication backends and resolves groups as members of groups.
comment:8 by , 14 years ago
Oh, I know the patch is ugly ;-) I'm neither a python nor SQL coder. I'm not really surprised that I made a big gaping security hole there, knowing this…
If it's any consolation, I reverted this and didn't look at it anymore about a week or so after posting here since I wanted to have full integration with LDAP, which this patch of mine obviously couldn't do - so I did some more dirty tricks (http://vanalboom.org/node/15). Your new patch seems to be much more generic so maybe I can revert this too and go back to a clean untouched trac. :-)
comment:9 by , 13 years ago
Keywords: | authzpolicy added; authz removed |
---|
comment:10 by , 12 years ago
I would love to have this feature, is there a recommend version I should use?
comment:11 by , 12 years ago
comment:12 by , 10 years ago
Status: | reopened → new |
---|
This appears to be a duplicate of #6680