I have used them similar to a Project in the past. But your example of
Pictures is good. The idea is that User3 might be the Owner of
Picture1, but only a Viewer of Picture2 and Picture3.
John McNally
Szűcs Attila wrote:
Hello !
I have been using Turbine for almost a year. I was always wondering on how
to use correctly the Turbine Security Schema.
As you know Turbine provides us User, Role, Permission, Group interfaces to
interact with.
I understand the use of Permission and Role. It's obvious that permissions need
to be organized into roles. The need for a User table is also trivial. But I
was thinking on why does the Turbine Security need a fourth abstraction layer,
the Group table. I am sure than many of you are familiar with this concept so
please correct me if I am wrong.
On the official Turbine site there is a very brief explanation. I have found an
article saying that the Turbine Group was not meant to group users. Instead it
is a context that permissions are assigned to. This approach describes the
power of groups in reusing permissions saying that a write Permission means
something slightly different in a user administrator or a server administrator
Group. I haven't had any situation where I could use groups as described above.
However, I can imagine a scenario where groups are used to group users around
certain objects.
Let's take look at this:
There is an object let's say a Picture. Each picture instance has an owner (the
user who created, or at least uploaded the picture). The owner of the picture
may grant different permissions (not the same as Turbine permission) to certain
users. These permissions are represented as roles as the following table
describes :
------------------------------------------------------------
Turbine_Role Turbine_Permission
------------------------------------------------------------
Viewer View,Comment
Editor View,Comment,Edit
Owner View,Comment,Edit,Delete
------------------------------------------------------------
In this case there may be many users of Picture1 that each have different
roles. User2 may have an 'Editor' Role while User1 may has 'Viewer' Role. Given
this situation we are forced to group the users around Pictures :
-------------------------------------------------
User1 User2 User3
-------------------------------------------------
Viewer X
Editor X
Owner X
--------------------------------------------------
It is possible that later on we will need to group users based on a different
criteria so we use a prefix for the Group names : PICTURE_ID where ID is the id
of the given picture. Other groups (like articles) will use other prefixes.
This is how I understand the use of groups in the security schema.
If this logic is wrong please correct me and please give an example of how this
should be used.
Thanks,
Atti
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
