back to phpList.org

Rest API subscriberDelete


#1

I’m integrating phpList 3.3.7 into a web shop using the Rest API.
I noticed that the subscriberDelete function only removes the specified user, not user_history etc.
The same applies to restapi2.

This is my fix (/lists/admin/plugins/restapi/includes/subscribers.php):

public static function subscriberDelete()
{
    //$sql = 'DELETE FROM '.$GLOBALS['tables']['user'].' WHERE id=:id;';
    try {
        if (!is_numeric($_REQUEST['id'])) {
            Response::outputErrorMessage('invalid call');
        }
        //$db = PDO::getConnection();
        //$stmt = $db->prepare($sql);
        //$stmt->bindParam('id', $_REQUEST['id'], PDO::PARAM_INT);
        //$stmt->execute();
        deleteUserIncludeBlacklist($_REQUEST['id']);
        //$db = null;
        Response::outputDeleted('Subscriber', sprintf('%d',$_REQUEST['id']));
    } catch (\Exception $e) {
        Response::outputError($e);
    }
}

The sql is replaced with the available deleteUserIncludeBlacklist function.

Any comments?


#2
  1. Thanks for sharing your findings
  2. It looks like you’ve modified the old REST API which is unmaintained, so using it in production may have security issues (nobody is monitoring that)
  3. Be careful with the deleteUserIncludeBlacklist function, as I recall it explicitly does not retain blacklist data, which means blacklisted subs can be Reimported or maliciously resubscribed. GDPR allows retaining a blacklist by my understanding, so that’s not an issue.

#3

Thanks for warnings. I’m not in production yet. To me it looks like restapi2 is not quite production capable either.

I’ve done all I can to harden the Rest API. I use these settings:

  1. Require SSL on Rest API calls: yes
  2. IP Address that is allowed to access the API: my Web Shop server ip address
  3. Require the secret code for Rest API calls: yes

I’ve also added quite comprehensive error logging into the Rest API Client, as well as modal dialogs showing limited error information to customers (and to my self, when testing).

No subscriber will be automatically confirmed. New subscribers get the standard email message asking for confirmation.

The phpList integration is inserted into the Web Shop as follows:

  1. Customers purchasing without an account
    During the checkout, when they enter their email, I notify if they haven’t subcribed or confirmed. In the first case they are offered an option to subscribe. In the latter case, they are offered an option to resubscribe (e.g. if they don’t have the previous message asking for confirmation any more).
    If they resubscribe, I simply delete the unconfirmed subscriber with the subscriberDelete function and add a new one. This ensures that the message asking for confirmation is sent.

  2. Customers registering an account
    The procedure is basically the same as in #1.

  3. Registered customers changing the details
    Customers can subscribe/unsubscribe a newsletter. In the latter case I use the subscriberDelete function.

Restapi2 misses the subscribe function. Also, the are no sendMail calls, like in the version I use. Any plans to add these?
It would also be nice to optionally send an email when unsubscribing using the Rest API.

Please add user cleanup also to restapi2:).

I’m not sure about GDPR and blacklisted subscribers. The tables user_blacklist and user_blacklist_data contain their email addresses.


#4

Sounds like a thorough integration – is it now working well?

Absolutely; hopefully some community contributors will help with this

What would user cleanup do?


#5

Working fine, thank you.

As I pointed out in my first message, If a subscriber is deleted via Rest API, we should also remove user history, etc. Otherwise there will be a lot orphan table rows in the db. I believe that those cannot be seen in admin.


#6

The standard functions used in phpList 3 for removing subscribers should be sufficient. If some of them leave behind so data it is possibly in order to avoid “rewriting statistical history” and retrospectively changing data about campaigns that were already delivered.


#7

The standard Rest API subscriberDelete only removes the user record, as seen above. Other user related data remain in the db and cannot be seen in the admin interface, because the primary record is gone.
That is why I replaced the standard code with deleteUserIncludeBlacklist.


#8

I did some debugging.

When I click ‘Remove subscriber’ in Admin Subscriber profile, the following functions will be called:

  • deleteUser
  • deleteUserLeaveBlacklist
  • deleteUserRecordsLeaveBlacklistRecords
  • deleteUserGroup
  • triggerDeleteUserPluginsHook

This is the least the Rest API subscriberDelete function should do, in my opinion.
As I pointed out, I want also delete blacklist recors.


#9

Because those functions are from phpList 3, and the new REST API uses phpList 4, they cannot be used directly there.

However as you’re using the old REST API you should be able to simply call those functions from within subscriberDelete for a more thorough removal.


#10

This is why it would be good to have similar functionality in Rest API v2 (phpList 4).

I think I saw somewhere a note “Rest API v2 can be used with phpList 3 DB”. Please correct me, if I’m wrong.


#11

Yes it’ll be good to have the same functionality in phpList 4.

Yes phpList 4 uses a phpList 3 database – they use the same data source.