MyBB Community Forums

Non-super admins will not be able to execute DROP, DELETE, TRUNCATE, etc. Noobs don't know how to add super-admins anyways. And noobs deserve it.

The only place I can see myself using this right now is on one of my hundreds of development boards. As I await the new version even with it I don't see myself running queries too often. The one day of a month I need to I don't see it to be beneficial. When I need that one query I will usually use phpMyAdmin by habit.

Good plugin but I do not take such risks, even if one gets ACP access by hacking or getting our password, he could create disasters. And yes a screenshot would be nice as well, please.

(2011-12-03, 01:54 AM)Paul H. Wrote: [ -> ]Non-super admins will not be able to execute DROP, DELETE, TRUNCATE, etc. Noobs don't know how to add super-admins anyways. And noobs deserve it.

Someone could simply perform a query to change the super-admin's UID and then, would be able to delete them normally as the super-admin protection would be removed.

(2011-12-03, 03:54 PM)Azareal Wrote: [ -> ]

(2011-12-03, 01:54 AM)Paul H. Wrote: [ -> ]Non-super admins will not be able to execute DROP, DELETE, TRUNCATE, etc. Noobs don't know how to add super-admins anyways. And noobs deserve it.

Someone could simply perform a query to change the super-admin's UID and then, would be able to delete them normally as the super-admin protection would be removed.

super admin status is in the config file, not in the database. if anything, he could make the plugin file require editing first to list the UIDs that can use it, then it does not matter what person is in the ACP as long as that person logged in is listed in the plugin file itself.

(2011-12-03, 04:02 PM)pavemen Wrote: [ -> ]

(2011-12-03, 03:54 PM)Azareal Wrote: [ -> ]

(2011-12-03, 01:54 AM)Paul H. Wrote: [ -> ]Non-super admins will not be able to execute DROP, DELETE, TRUNCATE, etc. Noobs don't know how to add super-admins anyways. And noobs deserve it.

Someone could simply perform a query to change the super-admin's UID and then, would be able to delete them normally as the super-admin protection would be removed.

super admin status is in the config file, not in the database. if anything, he could make the plugin file require editing first to list the UIDs that can use it, then it does not matter what person is in the ACP as long as that person logged in is listed in the plugin file itself.

Super-admin status is defined in the config file with a UID so, you could change the super admin's uid in the actual database as there is a uid column there and change your own with UPDATE.

That would be a good idea or could restrict it to super-admins only.

(2011-12-03, 04:06 PM)temp Wrote: [ -> ]Is it same as Labrocca's EZSql?

BTW that is paid and its free.

free? lol.

(2011-12-03, 04:02 PM)pavemen Wrote: [ -> ]

(2011-12-03, 03:54 PM)Azareal Wrote: [ -> ]

(2011-12-03, 01:54 AM)Paul H. Wrote: [ -> ]Non-super admins will not be able to execute DROP, DELETE, TRUNCATE, etc. Noobs don't know how to add super-admins anyways. And noobs deserve it.

Someone could simply perform a query to change the super-admin's UID and then, would be able to delete them normally as the super-admin protection would be removed.

super admin status is in the config file, not in the database. if anything, he could make the plugin file require editing first to list the UIDs that can use it, then it does not matter what person is in the ACP as long as that person logged in is listed in the plugin file itself.

Here's an example:

UPDATE mybb_users SET uid='60' WHERE uid='1'
UPDATE mybb_users SET uid='1' WHERE uid='20'

As the config file super-admin value works by uid, you can gain super-admin status.

but if a user does not have access to "MySquirrel" via a hardcoded variable in the tool itself in the first place, they can't run a query to update the UIDs.

(2011-12-03, 04:24 PM)pavemen Wrote: [ -> ]but if a user does not have access to "MySquirrel" via a hardcoded variable in the tool itself in the first place, they can't run a query to update the UIDs.

It would prevent them from doing that if that feature's implemented which I hope it is or some alternative method to securing it.
Although, the plugin author doesn't seem to intend on doing that from the posts that were made in this thread.