>
> One query I have is whether the above is completely the right fix in
> terms of the overall Turbine permission architecture? [No disrespect to
> Sam intended.]
>
> Specifically, is the 'turbine_root' role intended to be a sort of "super
> user" role that implicitly has *all* the available roles in a system
> (like the UNIX root user) without having to declare them one by one?
There should be no assumption of what permissions various roles have within
Turbine.
>
> It appears the intent of recent changes to the permissions / role system
> is to become more explicit about individual permissions, but I can't
> quite work out [yet] how (or even whether) permissions and roles are
> supposed to interrelate.
>
As far as I know, the user admin related stuff is still incomplete, so there
may be inconsistencies. For the most part, the permissions needed for a
specific application vary along with the roles they are assigned to.
Here is a short explanation of the user-role-permission system. In general
it is better to assign a specific permission to some task, for example,
"view_password". Then you assign this permission to a role, "admin". Then
in a screen that might show the password, you would first check to see if
the user (or more correctly, the session's acl, which is derived from the
currently logged in user) has the correct permission. The acl is created
by grouping all the permissions which have been assigned to roles which
belong to the user. It is also possible to to check for the role "admin",
before allowing the viewing of the password. But in the first case, if you
later decide that only a "super_admin", should be able to see passwords, you
can just use a web admin screen to reset the permissions associated with the
role "admin". If you start hardcoding role checks into your code you have
to change the code to change permissions.
So it is always a good idea to assign specific permissions to specific tasks
and group these into roles. Checks before performing an action, should be
on the permission, not the role. Though Turbine does allow the later. And
in a specific application it may seem to make more sense to perform checks
on roles. Though I would definitely recommend against it in general purpose
modules like those in Turbine.
I believe this may be counter to what is being done in the user admin
section, but like I said this section is probably not complete. Help
pointing out inconsistencies, along with patches is always appreciated.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
