I feel strongly that the operation of $S->have_perm() should not
change, especially to separate group and individual perms. This will add
significant unwanted complexity to permissions management. If group and
individual perms established, then they should be merged together to
establish one single permissions set when permissions are inspected for
a given user. To separate the requests in $S->have_perm() will make it
almost impossible to complete an overhaul of the permissions management
system at any point in the future.
In general, It's critical that we take great care before modifying
any box API methods. We should probably go through the code and decide
which methods call into the category of Box API methods so we can
establish a restrictive procedure for evaluating any changed to the
input/output of these methods.
It may also be worthwhile to maintain user perms (like group perms
now) in a separate table, rather than keeping them in the prefs table
primarily as a logical separation but also because site owners may make
the massive security mistake of allowing users to edit the 'permissions'
preference items, or even enable them. On that same issue, should
disabled preferences be editable by the $S->pref() or $S->set_pref()
methods? I haven't checked the code in this regard but I imagine you
can. Is this a good thing?
I don't know the answers to all these questions but I feel very
strongly that the operation of $S->have_perm() should not be changed to
separate user and group perms. From the permissions retrieval side,
there should be only one permissions filter to evaluate, before granting
or denying access.
-- Colin
Michael Bain wrote:
> * janra <janra at paradox.homeip.net> [27 Jan 2005 10:21]:
>
>>What about section perms? Would those be per-user changeable, or would
>>they stay as they are?
>
>
> Could be possible, have another two UserPrefs that let you allow or deny
> a particular pref for a particular section.
> ie. deny: "diaries:post,<somesect>:<someperm>"
> perhaps not those exact delimiters, but that general idea.
>
>
>>Also, $S->have_perm can get either perms for the current user, or for
>>some specified group. I'd imagine that the check for some specified
>>group would be the generic one that doesn't check your two proposed
>>prefs? $S->have_perm would need to be slightly modified to check
>>whether or not a group ID was passed in, which it currently doesn't do;
>>if you're checking a specified group and it happens to be the same group
>>as the current user, you'd get the current user's perms which may not be
>>what you were intending.
>
>
> I think, in that case have_perm should be changed so if you ask for a
> group's perms you get the group's perms; if you ask for a user's perms
> you should get that user's perms.
>
> Mike
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Scoop-dev mailing list
> Scoop-dev at lists.kuro5hin.org
> http://lists.kuro5hin.org/mailman/listinfo/scoop-dev