Walf

You don’t need any extra plugin if you want V3, the latter just works (once you’ve entered a correct key+secret pair). The whole point of a V2 plugin is to disable CF7’s built-in V3 support, so a V2 checkbox can be shown.

And another canned response. Failed to notice this was labelled as not a support question, did we?

I find such canned responses insulting. The linked thread explains very clearly what the issue is, in which your team already stated that it’s expected behaviour for the widget.

Better, but you’re still using sanitize_text_field instead of sanitize_textarea_field for the message body. It was more that when installing and testing your plugin, my first impression was that it broke breaking user input, which probably doesn’t instil trust for your average user.

Super prompt response, thanks.

Seeing the same. Fix your stuff, @facebook.

@maipiusenza I’m still of the opinion that a separate user is better, because then MySQL automatically limits what is available to the user (and thus in Adminer) without any program code to change the behaviour of Adminer or a plugin. As long as you’re aware of that, then do whatever works for you.

@pexlechris That’s just another band-aid. Raw SQL is also allowed in the Select, Insert and Update pages. Whilst your advice may work in this particular instance, they are the only person reading this, so it’s best not to spread false information about basic database access control.

@maipiusenza The only way to limit user access to specific tables and databases is with MySQL’s/MariaDB’s own permission system. Trying to block Adminer URLs containing table names is no substitute because there are many ways to read and modify data within Adminer, the most obvious being the SQL command page. You might need a stand-alone copy of Adminer to do what you want, but this could invite brute-force attacks so use very strong passwords.

@pexlechris I don’t know why you’re telling your users it’s possible.

New version is better.

Well done on plugging the security hole, but I’ll stick with the other one. Yours loads Adminer inside WordPress, which I think is asking for trouble given they are stand-alone applications, not written to share a global namespace or environment with anything else.

I don’t have time to help you fix your plugin.

I like Adminer, generally, and the previous plugin I used (ARI Adminer) got closed for security issues. I figured I should check how yours works before putting another compromised plugin on clients’ sites. Yours works but I’m not comfortable with how. I’m using the other Adminer plugin because it does security right as far as I can tell.

@pexlechris If you’re not going to address the issue, that’s up to you, but don’t mark the topic as resolved when your response is equivalent to “I don’t care that my plugin transmits the database credentials back and forth in plain text.” Allow your users to make an informed decision.

Just pick one of the permissions from https://www.ads-software.com/support/article/roles-and-capabilities/#capability-vs-role-table that only super-admins or single site admins have, e.g. update_core.

That still doesn’t change the fact that you’re echoing the raw db credentials out in the HTML. You’ve created a target for XSS by doing do. All an exploit has to do is fetch that page and send it somewhere else.