On Wed, Sep 30, 2009 at 7:29 PM, DrunkenMonk <[email protected]> wrote:
>
> Basically this was the most efficient way to enable multiple mysql
> users. And I must have multiple mysql users, in order to effectivly
> limit permissions on pages where guests could potentially construct
> their own queries
Ok, I understand now how you have it set up. Though it seems you ought
to use mysql users like 'read', 'edit', 'admin' and the like. Just to
make it clearer for the administrator using the plugin. I take it,
anyone writing an msql query in a function can assign it any user they
want, correct? It just has to be on the right page for that user set
of permissions to be executed. Which you have write protected. And
those permissions are first checked in site.auth.msql then sent to the
server if allowed.
> Technically I don't need anything new. I just don't want super-admin
> priveleges when I don't expect them.
Super admin status means nothing is forbidden to them. At least,
that's what I understand it to mean. If you want limited admin status,
set $BOLTadmin = ''; and appoint yourself to group.admin. (Not in that
order!). Then no one will have superadmin status, yet you can do
whatever you allow admins to do. I don't really want my installation
of BoltWire telling me what I can and can't do as super admin at
least.
>> So you end up with this:
>>
>> function BOLTauth($check, $find, $type, $admin=true) {
>> ...
>> if ($admin) {
>> if (strpos(" ,$BOLTadmin,", ",$find,") && $BOLTadmin != '')
>> return true;
>> }
>>
> This was pretty much what I was getting at, except I would have
> $admin=false as standard. It may be annoying in the core, but I think
> it is the expected behaviour for plugin writers.
Actually I assume superadmins have authorization automatically, admins
the auth assigned to them. However it occurs to me a smarter
implemention might be:
if ($find == $BOLTid) {
if (strpos(" ,$BOLTadmin,", ",$find,") && $BOLTadmin
!= '') return true;
}
This would not require any special parameter to disable this. Of
course, you could have a weird function name that just happens to
match your login id, or you might be generating a table of members to
see what auths they have, and a super admin gets a false return...
Maybe we'll just go with what we have, if it works for you.
Cheers,
Dan
P.S. The other reason I think the default should be true, is it would
mean I would have to go through every BOLTauth call in BoltWire and
every plugin and add a true parameter. I only had to set 3 instances
to false. Just empirically it seems the default should be true.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
