Re: Setup problems (List alive?)

Groups wrote:

> That's a lot of questions and maybe you won't have time to answer  them=
=20
> all but if you can give me some directions, that will save my day!

Your in luck .. my other work got delayed ..

> Let me try to explain what I want to achieve:
>=20
> The backend has the following user categories:
>=20
> (1) Admin:  has full access

so you want to set the "perm_type" to the LIVEUSER_SUPERADMIN_TYPE_ID=20
constant value (4 or higher to be exact). this way the given user has=20
all rights .. even if they are not even defined in the backend.

> (2) Staff includes (but should be able to add more groups if necessary)=
:
>     - administration department
>     - support department
>     - accounting department
>=20
>     Notes:
>     * Each department can have different permissions to the pages
>         Ex.    - admin department has access to the customers page +=20
> support page
>             - support department only has access to the support page
>             - etc.
>    =20
>     * Each page has its own permissions (Ex. show/add/edit/delete)

here liveuser supports 2 different approaches .. the most elegant one is=20
using right levels and ownership ..

by this the application developer is responsible to store which user (or=20
users) and/or group (or groups) own a given "object" you can to check a=20
permission on. the application developer is also responsible to retrieve=20
this data independent from LiveUser.

then when it comes time to check if someone has access to a given=20
"object" you call the checkRightLevel() method and pass the integer id=20
of the given right and the owner id's.

liveuser will then check if the user authenticated in the liveuser=20
instance has the given right or not. it will then also check the right=20
level at which the right was granted and depending on the value and the=20
owner id's it will finally return true or false.

to quote my liveuser article (that is currently offline it seems)
"LiveUser defines three different levels starting from one to three, the=20
later being the highest level. All higher levels include the lower=20
level. A right granted at level one means that the right may only be=20
applied if the =93perm_user_id=94 of the user who was authenticated match=
es=20
one of the ID=92s passed as the user owners. Granting a right at level tw=
o=20
also allows applying the right if one of the groups the authenticated=20
user is a member of is listed in the group owners. Finally with level=20
three the right can be applied without limitation."

--

the more complex solution means that for every object you create a new=20
area and all the relevant rights. this follows the RBAC approach also=20
explained in the article:

"One concept that developers may often be faced with is RBAC. There is a=20
thread on sitepoint [8] which serves as a good entry point to this topic=20
for readers whop are unaware of RBAC. Essentially RBAC provides the=20
following concepts in order to handle rights management: users, roles,=20
permissions, objects and operations. For example a question one might=20
want to ask in an RBAC system: =93Does a given user have a given role=20
which grants him a given permission to execute a given operation on a=20
given object=94. At first look it doesn=92t seem like LiveUser can actual=
ly=20
be seen as an RBAC implementation. However going through them step by=20
step one can actually see the corresponding concepts in LiveUser.

LiveUser obviously has the concept of =93users=94 and the concept of =93r=
oles=94=20
is also available. A right that has been granted to a user is simply a=20
=93permission=94. Now the next two concepts might not be so obvious.=20
Essentially in RBAC finding the right to check for is composed of two=20
pieces of information the =93object=94 and the =93operation=94. An =93obj=
ect=94 is=20
actually just a system resource that is subject to some sort of access=20
control. Therefore we just need a way of determining the access control=20
which will be checked before an =93operation=94 is allowed to be executed=
.=20
An =93operation=94 is for this reason just a right. Being able to determi=
ne=20
the right to check for when accessing an =93object=94 can either be done =
by=20
having a clear mapping between the different available types of objects=20
and a given area or by simply storing the right along with the actual=20
object."

> (6) Visitors : is not logged in / has only access to public pages =20
> (without any perms)

you can obviously get this by not checking rights. another alternative=20
is to just pass php null as the right_id to checkRight() or=20
checkRightLevel() .. this will also always return true ..

by the same token passing 0 as the right_id will always return true if=20
the user is logged in

> - How to use 'application'? Is there any predefined functions?

applications are just a categorization of areas
areas are just a categorization of rights

> - How to use 'seq'? Is there any predefined functions?

what do you mean? in the database containers liveuser will by default=20
use sequences or emulated sequences to generate new id's for users,=20
groups, rights etc.

> - How to use 'perm_type'? Is there any predefined functions?

there are a number of constants that define special perm types ..
currently only values of 3 or higher are relevant

3 means a lookup to the area_admin_areas table is made to determine=20
which areas the user should get all rights at level 3 from

4 or higher means the user gets all rights at level 3 automatically

> - How to use levels? Is there any predefined functions?

see above

> - How to setup area perms? group perms?

there are methods for this in the LiveUser_Admin package ..

see the example1 for sample API calls

> - How to setup and how to use owner_user_id and owner_group_id?

see above .. its your job to manage this data, although the configurable=20
storage layer in liveuser can help in this task. a bunch of examples=20
illustrate how to add custom columns (in theory you can even add custom=20
tables).

regards,
Lukas