> >> P.S. Just a thought, but shouldn't you have some kind of confirmation
> >> before executing an msql command with the potential to delete your
> >> entire site? And have you gotten stamp functionality to work, or just
> >> using the default stamps system. Just curious as the though of system
> >> wide incineration comes to mind. :)
>
> > Any query I don't have control over could potentially drop the entire
> > database, assuming the mysql user has privileges to do this. In order
> > to prevent this, I disallow myql users (the users on the mysql server)
> > based on pages, which means any query with sufficient rights to damage
> > the system is limited to site-pages or similar places.
>
> Not sure I follow this. How does your mysql function know which mysql
> user is calling the function? Are they a parameter in the function?
The first argument, yes. So
[(mysql Thomas "QUERY")] checks Thomas permissions to use mysql on
this page. Thomas will then have certain priveleges on the mysql
server.
On guest pages, I would instead enable SARA who has only read
permissions on the mysql database.
The point here is that boltwire must use one or more mysql users
anyway. The passwords are supplied in site.config, away from prying
eyes.
Limiting who can use which mysql_users doesn't make much sense to me.
If I make a page, I want everyone looking at the page to see the same
thing.
As such, I limit mysql users based on pages, meaning I can seperatly
define excecute permissions (view the page/query) and write
permissions.
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
So I set permissions based on mysql-users, not Boltwire users. Think
of each mysql user as a group of permissions...
> Parallel to the $BOLTid? And you have different rights for different
> kinds of querys? Like read data, vs store data, vs delete records or
> whole tables? Sound a bit complex...
Well, mysql has these permissions allready, I'm not adding any
complexity.
As I see it, the alternative is to restrict access to mysql users
based on member id, and that seems ... chaotic.
> The picture is not clear to me
> (pardon my denseness). I'm hesitant to make a fix without
> understanding exactly what you need.
Technically I don't need anything new. I just don't want super-admin
priveleges when I don't expect them.
> This should not be causing you problems unless you are using them,
> unless you mean it gave me pause before changing the BOLTauth
> function.
Nono, I just meant "your answer made me think about this."
> So you end up with this:
>
> function BOLTauth($check, $find, $type, $admin=true) {
> ...
> if ($admin) {
> if (strpos(" ,$BOLTadmin,", ",$find,") && $BOLTadmin != '')
> return true;
> }
>
> What do you think about this possibility? Would it meet your needs? It
> seems to solve the problems you pointed out above. I've added this to
> my source code for the next release unless it doesn't work for you, or
> you see some problem with it.
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.
>
> Cheers,
> Dan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
