jacopol

Yes I’ll go with the $wpdb methods since it’s the only way this is stable. I’m replicating the sanitization and filters from wp_insert_user() so I should be safe. Also, the endpoint is never exposed publicly and it’s only accessed by the AWS Lambda that is triggered by users purchasing a product, so the environment where all this happens should be relatively controlled. Also considering I do all the checks on application password and what not way before the user insertion is ever needed.

For the few filters I’m skipping, I checked and nothing is really done on those, except for wp_pre_insert_user_data of course, where TML does the password hashing. Since I take explicit care fo the hashing myself, everything should be good.

Thank you for your help! I’ll update here if I ever manage to fix this without the current workaround.

One thing I don’t understand, about the possible explanations related to the corrupted state of Theme My Login and the issue with the hashed password: How are these only affecting the requests sent from my AWS Lambda (in my staging website)? The cached Theme My Login state is not depending on the HTTP request source and the password is internally generated by the plugin, so completely independent from the HTTP request.

This is what I’m using to print for debugging. I added conditions to directly check what the if case causing the error is evaluating.

add_filter( 'wp_pre_insert_user_data', function( $data ) {
  error_log( print_r( $data, true ) );
  error_log( is_array($data) ? 'is array' : 'is NOT array' );
  error_log( empty($data) ? 'is empty' : 'is NOT empty' );
}, PHP_INT_MAX );

This is what’s printed

[04-Feb-2024 20:40:57 UTC] Array
(
    [user_pass] => $P$B6jXtADMIdzWpoij5dafcvqfLLgJxy0
    [user_nicename] => jacopoprovaprova-com
    [user_email] => [email protected]
    [user_url] => 
    [user_registered] => 2024-02-04 20:40:52
    [user_activation_key] => 
    [display_name] => Jacopo Prova
    [user_login] => [email protected]
)

[04-Feb-2024 20:40:57 UTC] is array
[04-Feb-2024 20:40:57 UTC] is NOT empty

So everything looks correctly composed to me, and, as long as my host is not doing some custom development over the WP open source code, I don’t see how that if case is triggering the error.

As I mentioned, my staging website still works when the request is arriving from my local machine. My staging website uses a different theme (the standard Twenty* one) while my production uses the Intentionally Left Blank theme, since I use Oxygen builder that overwrites it. The plugin on my production website broke (for requests coming from my local machine) with the theme not changing since the plugin was working, so I don’t think the issue is related to the theme. But I can do some more test there.

On my local WP installation my plugin works. Also there I have the Twenty* theme (although a different one). Unfortunately my host doesn’t provide access to wp-includes/ so I don’t have a way to check if any custom code was added to the open source WP installation. I contacted them regarding the issue and I’m waiting for an answer.

The API endpoint I’m using is a custom one I added. I have some custom tables I add rows to when receiving the POST request, so my plugin (listening to the custom endpoint) takes care of everything. In some cases, depending on the body of the request, I have to add the new user. So it was easier to just call wp_insert_user() instead of invoking the WP REST API just for that.

Thank you for the password hint. I simply used wp_generate_password() assuming is was compatible. It’s not important since the password is just a place holder.

Thank you for you answer. Which kind of poorly considered security measure are you thinking about?
Trying again tonight gives the same error even when sending the request from my local machine. Not a step forward, but makes more sense.

Since this is how the wp_insert_user() looks like when giving that error

	$data = apply_filters( 'wp_pre_insert_user_data', $data, $update, ( $update ? $user_id : null ), $userdata );

	if ( empty( $data ) || ! is_array( $data ) ) {
		return new WP_Error( 'empty_data', __( 'Not enough data to create this user.' ) );
	}

I tried to intercept $data right before calling wp_insert_user() with this

add_filter( 'wp_pre_insert_user_data', function( $data ) {
   error_log( print_r( $data, true ) );
}, 20 );

and the printout looks reasonable and definitely not empty

[user_pass] => $P$BNIhibiz/od63ARGcF5NfjAKEVHaxV0
[user_nicename] => johndoejohndoe-com
[user_email] => [email protected]
[user_url] =>
[user_registered] => 2024-02-01 20:26:07
[user_activation_key] =>
[display_name] => John Doe
[user_login] => [email protected]

I tried to add the missing fields (user_url and user_activation_key) but it made no difference.