Corrigir um plugin wordpress

Corrigir detalhes apontados pelo wordpress :
## Using CURL Instead of http api

wordpress comes with an extensive http api that should be used instead of creating your own curl calls. It's both faster and more extensive. It'll fall back to curl if it has to, but it'll use a lot of WordPress' native functionality first.

https://developer.wordpress.org/plugins/http-api/

Please note: If you're using CURL in 3rd party vendor libraries, that's permitted. It's in your own code unique to this plugin (or any dedicated WordPress libraries) that we need it corrected.

Example(s) from your plugin:

wc-notification-api-in-cell/includes/class-get-z-api-io.php:61: $response = curl_exec($client);

## Using file_get_contents on remote files

Many hosts block the use of file_get_contents on remote content. This is a security measure that we fully endorse.

Thankfully, Wordpress comes with an extensive http api that can be used instead. It's fast and more extensive than most home-grown alternatives. It'll fall back to curl if it has to, but it'll use a lot of WordPress' native functionality first.

https://developer.wordpress.org/plugins/http-api/

Please note: If you're using file_get_contents in 3rd party vendor libraries, that's permitted. It's in your own code unique to this plugin (or any dedicated WordPress libraries) that we need it corrected.

Example(s) from your plugin:

wc-notification-api-in-cell/includes/class-get-z-api-io.php:87: $response = file_get_contents("https://api.z-api.io/instances/$this->instances/token/$this->token/qr-code/image");

## Data Must be Sanitized, Escaped, and Validated

When you include post/get/request/file calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: Data that is input (either by a user or automatically) must be sanitized as soon as possible. This lessens the possibility of xss vulnerabilities and mitm attacks where posted data is subverted.

VALIDATE: All data should be validated, no matter what. Even when you sanitize, remember that you don't want someone putting in 'dog' when the only valid values are numbers.

ESCAPE: Data that is output must be escaped properly when it is echo'd, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.

To help you with this, WordPress comes with a number of sanitization and escaping functions. You can read about those here:

https://developer.wordpress.org/plugins/security/securing-input/
https://developer.wordpress.org/plugins/security/securing-output/

Remember: You must use the most appropriate functions for the context. If you're sanitizing email, use sanitize_email(), if you're outputting HTML, use wp_kses_post(), and so on.

An easy mantra here is this:

Sanitize early
Escape Late
Always Validate

Clean everything, check everything, escape everything, and never trust the users to always have input sane data. After all, users come from all walks of life.

Example(s) from your plugin:


wc-notification-api-in-cell/wc-notification-api-in-cell.php:248: $first_name = trim($_POST['first_name']);
wc-notification-api-in-cell/wc-notification-api-in-cell.php:329: $customer_name = trim($_POST['first_name']);
wc-notification-api-in-cell/includes/settings-admin.php:18:$tab = (isset($_GET['tab'])) ? trim($_GET['tab']) : '';
wc-notification-api-in-cell/includes/settings-admin.php:19:$action = (isset($_GET['action'])) ? trim($_GET['action']) : '';

wc-notification-api-in-cell/includes/settings-admin.php:35: $post_settings = (array)$_POST;
wc-notification-api-in-cell/includes/settings-admin.php:53: $post_messages = (array)$_POST;

Note: We strongly recommend you never attempt to process the whole $_POST/$_REQUEST/$_GET stack. This makes your plugin slower as you're needlessly cycling through data you don't need. Instead, you should only be attempting to process the items within that are required for your plugin to function.

## Variables and options must be escaped when echo'd

Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.

At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'

Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.

This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.

Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!

There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.

https://developer.wordpress.org/plugins/security/securing-output/

Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.

Example(s) from your plugin:

wc-notification-api-in-cell/wc-notification-api-in-cell.php:191:            <a href="<?php echo $myaccount_page_url; " class="single_add_to_cart_button button alt<?php echo esc_attr( wc_wp_theme_get_element_class_name( 'button' ) ? ' ' . Wc_wp_theme_get_element_class_name( 'button' ) : '' ); ">
wc-notification-api-in-cell/includes/settings-admin.php:639:                    get_qrcode.open("GET", "https://api.z-api.io/instances/<?php echo $instances; /token/<?php echo $token; /qr-code/image");
wc-notification-api-in-cell/includes/settings-admin.php:439:                                <textarea class="form-control form-text" name="register_order_text" cols="5" rows="3" style="width: 100%; max-width: 500px;"><?php echo $register_order_text; </textarea>


## Setting a default timezone

This is rarely a good idea. People should be able to define their own timezones in WordPress.

Also WordPress explicitly sets and expects the default timezone to be UTC (in settings.php) and the date/time functions sometimes rely on the fact that the default timezone is UTC. For instance if you do date_default_timezone_set(get_option('timezone_string')) and then later try to get a GMT timestamp from get_post_time() or get_post_modified_time(), it will fail to give you the right date.

Example(s) from your plugin:

wc-notification-api-in-cell/wc-notification-api-in-cell.php:25: date_default_timezone_set('America/Sao_Paulo');
wc-notification-api-in-cell/includes/settings-admin.php:15:date_default_timezone_set('America/Sao_Paulo');

## Generic function/class/define/namespace names

All plugins must have unique function names, namespaces, defines, and class names. This prevents your plugin from conflicting with other plugins or themes. We need you to update your plugin to use more unique and distinct names.

A good way to do this is with a prefix. For example, if your plugin is called "Easy Custom Post Types" then you could use names like these:

function ecpt_save_post()
define( 'ECPT_LICENSE', true );
class ECPT_Admin{}
namespace EasyCustomPostTypes;

Don't try to use two (2) or three (3) letter prefixes anymore. We host nearly 100-thousand plugins on WordPress.org alone. There are tens of thousands more outside our servers. Believe us, you're going to run into conflicts.

You also need to avoid the use of __ (double underscores), wp_ , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please remember, if you're using _n() or __() for translation, that's fine. We're only talking about functions you've created for your plugin, not the core functions from WordPress. In fact, those core features are why you need to not use those prefixes in your own plugin! You don't want to break WordPress for your users.

Related to this, using if (!function_exists('NAME ')) { around all your functions and classes sounds like a great idea until you realize the fatal flaw. If something else has a function with the same name and their code loads first, your plugin will break. Using if-exists should be reserved for shared libraries only.

Remember: Good prefix names are unique and distinct to your plugin. This will help you and the next person in debugging, as well as prevent conflicts.

Example(s) from your plugin:

wc-notification-api-in-cell/includes/class-get-z-api-io.php:16: class Get_API {
wc-notification-api-in-cell/wc-notification-api-in-cell.php:34: class WC_Notification_Api_WhatsApp {


--
WordPress Plugin Review Team | plugins@wordpress.org
https://make.wordpress.org/plugins/
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/