UniverseUniversity


Home Projects Jobs Clientele Contact

uu


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: User 'Everybody'



As I mentioned, each person will have their own group, that they will
be single member of. For "personal" access, this group will be granted
access to. Of course, UI may present it as if it was something special, but
internally we'll be using same group concept.

Regarding changing ACLs - yes you are right, synchronization may
be _bit_ of a problem. Since relationship between temp table and actual
ACLs doesn't last more then single request, anything that modifies the
ACLs can take care of synchronization if needed (i.e. by calling login()
again).

Re class - yes, it is special case of group. Furthermore - it's really just
a group. _Any_ group can have membership granting rules. This makes
things most flexible, I think. If we need to differentiate between kinds of
groups based on purpose, we can do it in application, since data integrity
will not be violated in any case.

Alexey Parshin wrote:
> Do you want group AND personal ACLs or just group ACLs?
> Also, if this temp table is large enough (several thousand records) -
> we really need pconnect implementation. Oh, there is a side effect of
> temp tables with ACL. If an ACL is changed/added/removed during the
> session by someone else, we ether need a trigger updating it
> (expensive) or logoff/logon to see the effect of the change.
> BTW, besides class price, class is logically identical to group, isn't it?
>
> 2007/4/15, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     I am aware of slow-down effect, and it's the thing that worries me
>     the most.
>     Off top of my head, one way to at least soften the impact, is to
>     create temp
>     table with groups _current user_ is part of at login() time. This
>     way at
>     least
>     we will not have to look it up on every query that requires access
>     checking.
>
>     However, before diving into implementation difficulties, I would
>     like to
>     see if
>     there are principle matters - i.e. if there are any problems in
>     terms of
>     usability
>     of application itself.
>
>     Alexey Parshin wrote:
>     > The first result of having a group permissions is some slowdown.
>     > Currently, to check an access, we have to find a single ACL record.
>     > With the group access - we have to find a group and ACL record
>     > combinations, and then find if any of the found combinations
>     grants an
>     > access.
>     >
>     > 2007/4/15, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>
>     > <mailto:ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>>>:
>     >
>     >     OK. I finally got around to thinking about this problem.
>     >     First thing that comes to my mind when thinking about
>     >     this, is adding a concept of a group.
>     >
>     >     All rights in this case would be granted to groups of people.
>     >     Each person would have group with only his account in it
>     >     created automatically, for granting individual access.
>     >
>     >     Each person would belong to "Everybody" group.
>     >
>     >     Groups can be created by anyone. Membership access rules
>     >     would be same as in my proposal for classes. In fact classes
>     >     are just special case of groups, and would be replaced by
>     >     this proposal.
>     >
>     >     Then, once group is created, rights can be granted to that
>     >     group.
>     >
>     >     In example with courses & classes, Author would set group
>     >     access policy (i.e. group admin has to pay, in order to get
>     >     his group access to the object), and teacher would create
>     >     group "classFall2008AbraKadabraCourse", and set membership
>     >     rules for that group, and then would get "study" access to
>     >     the course for this group.
>     >
>     >     Comments?
>     >
>     >     Alexey Parshin wrote:
>     >     > For the purposes when we have to allow a certain right to
>     >     everybody,
>     >     > like: 'Everybody may study this object', it makes sense to
>     have
>     >     a user
>     >     > 'Everybody' (or 'Public').
>     >     > This change means we have a record with fixed id=2 (id=1
>     is reserved
>     >     > for no user, or 'Nobody') and is_authorized() stored proc is
>     >     changed
>     >     > to check the user permissions, and, if not available, public
>     >     permissions.
>     >     >
>     >     > --
>     >     > Alexey Parshin,
>     >     > http://www.sptk.net
>     >
>     >     --
>     >     Ilya A. Volynets-Evenbakh
>     >     Total Knowledge. CTO
>     >     http://www.total-knowledge.com
>     >
>     >
>     >
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net < http://www.sptk.net>
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> -- 
> Alexey Parshin,
> http://www.sptk.net 

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com


Authoright © Total Knowledge: 2001-2008