"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Yup, or some access mask like Read/Write/Delete or whatever. My take is
> that it may be ok to generalize these very common attributes(drawing
> expereince from file system) but the actual matching better be
> delegated to the user modules.
Which FS? With or without ACLs? ;-) I believe this can be dealt with by
specific restrictions in methods. See below (and my other post asking if
there's some way to have "identity" applied to all "subdirectories" of my
website).
> Especially like some want groups, but how about nest groups ? How about
Nested groups are a PITA to manage. I dunno if it is worth having them.
Specially if you want to have an API instead of some implementation. Having
nested groups using an RDBMS should be easy, but how about using text files?
(LDAP also handles nesting very easily...)
In fact, the method that should return "OK"/"NOK" should handle this nesting
for you.
> roles ? How about default not allowed but allowed selectively ? How
Would roles be something related to
turbogears.identity.model.somodel.Permissions?
The selectivity could be dealt with decorators being applied to individual
methods. Then you could define a "global" behaviour and change it with
decorators as it is done today.
Maybe using a class properties such as
- defaultBehaviour = 'allow' | 'deny'
- defaultRestriction = "group='group'" | "user='user'" |
"group='group', user='user'" | ...
and so on. Then, the filter checks that and do what they say. This would
reduce a lot of code and would allow us to have restrictions "per
class/module".
> about default allowed but deny selectively ? We have the advantage of
See above. It's the same case, with an opposite default.
> using a SQL(in some form) which is really good at these kind of things.
Be seeing you,
--
Jorge Godoy <[EMAIL PROTECTED]>
