Re: Proposal: User 'Everybody'

["Alexey Parshin" <alexeyp@gmail.com>]

What we are changing is at least:

1) Adding group_list table with groups.
2) Adding user_to_group table to include user into group
3) Changing ACLs from referring to person_list to referring to group_list

The most concern is that instead of simple query to get an ACL like:

SELECT tla_access FROM topic_list_acl
WHERE tla_person = ? and tla_topic = ?

we would have:

SELECT tla_access FROM topic_list_acl, user_to_group
WHERE 
    utg_group = tla_group AND utg_person = ?
    AND tla_topic = ?

Of course, I may make a compound index on (utg_group,utg_person) but we still have a join never the less.

Creating a temp table with materialized view of ACLs for that user would speed it up, IF we have persistent connection that is controlled by the session id. Otherwise - the generation of such temp table may slow us down. BUT, if we make this persistent connection, then we cannot change user's permission while that user is logged in :(

2007/4/16, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Alexey Parshin wrote:
> I think, we're opening a can of worms here.
I'd like to hear specifics please :)
> Having group-level security slows us down, but what do we have as
> advantage?
Easier management.  Previously we didn't have any provisions for
differentiating
between groups of users of objects.
> I know how to implement it, it's just little bit strange.
What is strange about groups?
> So, if you really want it - I'd start changing schema.
I am still undecided. If you show me some real problems, I may change
my mind. If you can quantify performance impact, it'd help decision-making
too.
> It also means that I'd have to redo most of the work done for last two
> weeks :(
Well, things do not change _that_ much - we just replace users with
groups in
access checking procedures..
>
> 2007/4/16, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     Alexey Parshin wrote:
>     > I'm reading your e-mails. I just don't see the need to work with
>     > single-user groups, at least - I'd prefer not to create such
>     groups as
>     > a part of user-creation process.
>     How do you grant access to individual users then? Create a
>     new single-user group every time it's needed?
>     > Also, creating a group 'Everybody' would probably simplify a
>     > permission search but it would also slow it down. I propose to
>     create
>     > such group but don't include anyone in there - we can simply assume
>     > all the users are there in our SQL.
>     So, you want to special-case it? Wouldn't that slow things down
>     just as
>     well?
>     Although.. I guess we could populate groups temp table with group
>     Everybody,
>     without having data in permanent table.. Hmm.. I'll say - your call..
>     >
>     > 2007/4/16, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com >
>     > <mailto: ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>>>:
>     >
>     >     Man, aren't you reading my mails? ;-)
>     >     If you need to give access to single individual, you use
>     >     their personal group. This avoids having to search through
>     >     two tables, thus making code simpler.
>     >
>     >     Alexey Parshin wrote:
>     >     > What's the idea behind a group per person?
>     >     >
>     >     >
>     >     > < 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
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

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

-- 
Alexey Parshin,
http://www.sptk.net