Nonstop Security Digest Email Notifications and No Default Recipients[user_list]

I decided to disable the iThemes Security plugin until I upload the new site because there’s just too many Weekly Security Digest emails coming from it.

Another Thing I Tried
I changed the From email in the Notification Center so I could create a delete rule in my email inbox, but the notifications continue coming from the default address WordPress <[email protected]>.

Hi Jamisons,

Finally a topic that includes all required data ! So that deserves some attention;-)

It seems the iTSec plugin UI isn’t able to persist the value for default_recipients, user_list. Not sure why.

But we can try and put in a value manually from the iTSec Debug page.

There are 2 different types of values possible.
First one is a role (string) which would look like this:

    "default_recipients": {
        "user_list": [
            "role:administrator"
        ]
    },

This corresponds to the All “Administrators” Users value in the Notification Center UI.

The second type is a user’s ID (integer).
Typically for the default administrator user the ID would be 1 as can be seen below (but it doesn’t have to be that way):

    "default_recipients": {
        "user_list": [
            1
        ]
    },

Editing this setting’s value manually is a bit experimental. The plugin interface may undo the change any time you try and save some other setting. This doesn’t address the root cause of the issue. Please keep that in mind.

Try it and let me know the result.

Oh, when editing manually in the Debug page, make it look exactly as shown above. After trying myself, it seems indenting is taken care of automatically.

• This reply was modified 2 years, 10 months ago by nlpro.
• This reply was modified 2 years, 10 months ago by nlpro.
• This reply was modified 2 years, 10 months ago by nlpro.
• This reply was modified 2 years, 10 months ago by nlpro.

Thanks for the reply. I tried adding the user number earlier. When I clicked save, it kept the number, but displayed the error atop the debug page: Default Recipients[user_list] must contain at least 1 item.

When I load the setting, the number is gone again. I will try role:administrator now.

No luck. Get the same error, and reloading the settings removes the user info.

Ah right, that’s probably because the Debug page Save action performs the same sanitation/validation as the plugin UI does.

Hmm … let me think about that.

Thanks, I’m calling it a night. I’m not opposed to reinstalling the plugin. But my main concern is whether this plugin is reliable. I’ve been using it for about 10 years on other sites and never had this problem. Appreciate all your input in these forums. Have a good night.

Ok, no problem.

Meanwhile I’ve been looking at this top to bottom.

All the Debug page Save button does is a POST of the admin-ajax.php script. And it works just fine in my test environments.
So I’m thinking there is something specific in your env that breaks things.

Warning: The text below is pretty technical.

The admin-ajax.php POST request runs the handle_ajax_request() function from the core/admin-pages/page-debug.php file.

It does perform a data conversion and subsequently passes the result to a function that will persist the (Notification Center) settings in the database:

//$method = 'save_settings';
//$module = 'notification-center';
...
$data = json_decode( wp_unslash( $_POST['data'] ), true );
...
$result = ITSEC_Modules::set_settings( $module, $data );

However before persisting the data in the database it is first validated (and sanitized).

The Notification Center validation function (validate_settings()) can be found in the core/modules/notification-center/validator.php file. This is where it actually gets interesting.
It will first attempt to run a generic validation function:

parent::validate_settings();

In there it calls a WordPress core REST API validation function like below:

$valid = rest_validate_value_from_schema( $this->settings[ $setting ], $schema, $param );

This is the validation that ultimately generates the error:

Default Recipients[user_list] must contain at least 1 item.

So this is actually a WordPress Core REST API error msg.

The validation chokes on the user_list property "minItems": 1, requirement as defined in the core/modules/notification-center/module.json file:

     "default_recipients": {
        "type": "object",
        "additionalProperties": false,
        "required": [
          "user_list"
        ],
        "properties": {
          "user_list": {
            "type": "array",
            "minItems": 1,
            "items": {
              "oneOf": [
                {
                  "type": "integer",
                  "minimum": 0
                },
                {
                  "type": "string",
                  "pattern": "^role:\\S+$"
                }
              ]
            }
          }
        },
        "default": {
          "user_list": [
            "role:administrator"
          ]
        },
        "title": "Default Recipients",
        "description": "Set the default recipients for any admin-facing notifications."
      },

It means the user_list array value needs to have at least 1 value.
So one way or another the value gets lost in your env.

Perhaps the info above helps you trace/debug the issue. I’m going to have a good night sleep. Who knows I’ll have some new ideas tomorrow ??

These details are amazing; over and above all expectations. Thank you so much.

I compared the files and functions mentioned and they are identical to the original plugin files. So it does sound like something in my env causing the problem. Thanks a bunch.

When I installed iThemes security, I ran the feature to remove user with ID 1. Wonder if that caused an issue.

Thank you for your kind words.

There was an issue in that area but according to the 8.0.2 Changelog it got fixed:

Bug Fix: When the Change Admin User tool is run, update any User Groups referencing the old user id.

Before diving any further into the plugin code let’s try and rule out (if not already):

– the possibility of a plugin conflict. If possible deactivate all other plugins and see whether the issue persists (or not).

– the possibility of a PHP version issue. If possible try using PHP 7.4.x (instead of the current 7.3.33).

• I upgraded to PHP 7.4 last night and the problem persisted.
• Deactivated all other plugins and problem persisted.
• Deactivated and reactivated iThemes Security. Non-stop digest emails resumed upon reactivation and error persists in Notification Center: Default Recipients[user_list] must contain at least 1 item.

Would it be beneficial to try a fresh install of iThemes Security?

Ok, I see.

A fresh install of iThemes Security won’t hurt. So go ahead and deactivate and uninstall the plugin. Then reinstall. Don’t really expect it to resolve the issue(s), but you never know.

One other thing, what browser and what client platform (eg Windows 10/11)/hardware are you using ?

Will do now. I’m using Firefox 95.0.2 on Mac OSX 12.0.1

Reinstalled and configured and no error so far. I did change the default recipients to see if the error would occur and it did not. However, I believe the problem began when the first weekly digest happened, so we’ll see in a week.

If the error was caused by the setting the removed user ID 1, maybe whatever that process was didn’t need to run this time because user 1 didn’t exist.

Thanks for now. Will reply if the problem resumes.

Ah, excellent.

So it looks like the issue was in the iTSec plugin metadata as saved in the database. And yes, the root cause could very well be the “Change User ID 1” tool.

Looked at the code run by the “Change User ID 1” tool and YESSSS it doesn’t update the ID 1 in the Notification Center default_recipients[‘user_list’] array (which is definately a bug).
It only does that for Notification Center notifications[] !
Like the notifications[‘digest’][‘user_list’] array, etc.

BUT if the notifications[‘digest’][‘recipient_type’] is set to “default” it will still attempt to use the UNCHANGED (and invalid) user ID value (1) from default_recipients[‘user_list’] to send the email!

This evening I’ll setup a new test environment and test the above scenario. Just to be sure.

When going through the validation code earlier, I did notice a chunk of code that checks for invalid user IDs. Any invalid user IDs are removed, but I don’t think that piece of code checks whether there are any user IDs left. That could ultimately explain the empty default_recipients[‘user_list’] array …

Looks like we are on the right track ??

Astounding work. Really appreciate your service.