Tag Info

New answers tagged

1

This is a very vast question so excuse me for not adding code. I do have a map for you. For sensible reasons, WordPress doesn't have a hook or filter that can help modify user passwords before they are saved in the database. The solution proposed by @jason-murray will hide the password fields in one location — on the user profile page. However, users ...


1

You can use this code in your functions.php to restrict users below admin level from changing their passwords: if ( is_admin() ) { add_action( 'init', 'disable_password_fields', 10 ); } function disable_password_fields() { if ( ! current_user_can( 'activate_plugins' ) ) { $show_password_fields = add_filter( 'show_password_fields', '__return_false' ...


1

Well to say that these custom fields are insecure in the wp core tables is to say that the usernames and passwords are also insecure, along with any private or password protected posts. As long as you are not outputting these custom fields anywhere but a secure page for logged in, paid up users, no one could retrieve them without server side access to run a ...


0

My first thoughts are to SSL the entire site due to the nature of the project. There are also things you can do to forms to make them safer, when recently reading the Stripe payment gateway documentation they suggest not adding a name attribute to the fields in the form until the final second with some javascript. SSL and no mixed content loading (which is ...


1

If you can't modify anything on the server (site fully static) then there is no point in trying to break into it. In enterprise kind of setting you can achieve this by limiting login and restricting write permission to only people coming from the local network, but for most people this kind of setting is too hard to configure and maintain, and doesn't fit ...


0

You could use "save_post" hook to capture all submit within WP, for ex: function just_got_you( $post_id ) { if ($post_id != '123') return; << do your logging stuff here >> } add_action( 'save_post', 'just_got_you', 10, 2 ); Change 123 to your page/post id. More reference here Save Post Hook


0

When accepting user data inputs, I think that data validation must be performed if possible, not only sanitization. For example, you could expect a number, a bool value, a text string (even when the input is a selectbox it can have a string value), etc. You can santize for that data types; then you can go further and validate the data against expected ...


0

You can use any of the sanitation functions built into Wordpress (such as sanitize_text_field). Alternatively, if you are worried about specific elements being injected into the select options you can write you own sanitation function with the sanitize_meta function.


0

There is no need to stop "plugin enumeration", just use plugins from a good home and make sure you have restrictive file permission setting on your server. In theory you can use htaccess to mask the original location of the plugin on the disk and write some code to serve any JS and CSS file as if they are located at some other directory, but this depends on ...


2

Your plugin users will need to register their site at https://www.google.com/recaptcha/admin to use the reCAPTCHA API. Once registered, users will need to provide you with their Site Key and Secret Key. The Site Key allows you to display the reCAPTCHA on your Registration form. The Secret Key is used to confirm the reCAPTCHA field input.



Top 50 recent answers are included