View Issue Details

IDProjectCategoryView StatusLast Update
0015300phpList 3 applicationSubscribe Processpublic23-04-10 16:02
Reporterspiro Assigned To 
Status resolvedResolutionfixed 
Product Version2.10.10 
Target Version2.10.12Fixed in Version2.10.12 
Summary0015300: Resubscribing previous user (i.e. blacklisted)
DescriptionThere are two possibilities with this depending on whether users are required to use a password.

config.php define("ASKFORPASSWORD",0);

With the above setting in config it still only works if a fix that I found in the forum is applied to the admin/subscribelib2.php around line 365 under "if ($blacklisted) {" rem out "return 1". This then allows the new subscription to send out the request for confirmation email and once the url in that is clicked the user is removed from being blacklisted.

With the ASKFORPASSWORD set to 1, when someone tries to resubscribe the subscription page asks for a password to be created and then reconfirmed as with any user trying to subscribe with the password option switched on. However, instead of the system updating the password with the new one from this registration as it does with the rest of the user details being resubscribed, it reloads the subscribe page stating that the email already exists with a different password, breaking the resubscription process unless the user knows or requests their old password. It would be cleaner if whatever password they chose upon attempting to resubscribe was taken as their new data as it does with other attributes from the subscribe page.
TagsNo tags attached.


Thorsten Albrecht

11-08-09 11:34

reporter   ~0050709

Regarding the configuration without using any passwords:

I decided to apply the solution proposed in (Point 2):

"If a user is blacklisted and re-subscribes, the "thank you page" displays an alert message to inform the user that he is blacklisted and that he should contact the administrator. In fact, it is not necessary because the user receives a confirmation email with a confirmation link. By clicking on the confirmation link, the user is confirmed and removed from the blacklist.

We can safely remove the warning message."

By uncommenting out the code as described, now a user can resubscribe by himself. The whole stuff with "the administrator has to put you manually from the blacklist" is not necessary anymore. (BTW I a newsletter system, there shouldn't be any manual interventions by the admin in the (re-)subscribing process.



29-08-09 17:31

manager   ~0050729

The issue described by spiro seems related to the one described by docdunning:

====== Start Quote ======

I wanted to make sure that users have to provide their password when unsubscribing. So I used the config file to set ASKFORPASSWORD and UNSUBSCRIBE_REQUIRES_PASSWORD.

But the process just didn't work properly. I've had to make several mods to index.php to get it to work.

1. The login page HTML was not properly generated. It appeared on a blank page with no styling. This was because the $data variable wasn't being passed into the loginpage function.
2. More seriously, the details for the user were not being found in the database, because the code uses $_GET['email'], and the login form obviously sends in $_POST['email'].

====== End Quote ======


06-10-09 18:19

reporter   ~0050748

I've changed my setup since reporting this as I changed host and now use a joomla component from foobla for the user front end integration with my joomla site.

I can't previously recall experiencing the issue quoted above that docdunning has experienced, but I may not have been requesting the use of the password for unsubscribes, I may have only been using it for user preference updating. I think I may have been using the uid version of the unsubscribe url.

I am now also experiencing the docdunning issue on a new install of v2.10.10. Even though I have the password variables set in the config file as described by docdunning above, using the non uid unsubscribe url does not request the password to be supplied so someone could therefore unsubscribe someone elses email. Previously I wasn't experiencing this as I wrote a custom unsubscribe form for my site that blended with that design so I was controlling whether a user had arrived at my site from a uid version url and if not redirecting them to my home page so they could only access my unsubscribe page in one way and then used curl to submit my form to the phplist unsubscribe form.

Anyway, having looked at my notes I believe I found a fix to allow a user that has previously unsubscribed to resubscribe without needing their original password by making the following 2 changes. This was the original purpose of this issue, I think the docdunning issue is a seperate one to this.

First find the following block of code in admin/subscriblib2.php starting around line 172.

if (ASKFORPASSWORD && $old_data["password"]) {
         if (ENCRYPTPASSWORD) {
            $canlogin = md5($_POST["password"]) == $old_data["password"];
         else {
            $canlogin = $_POST["password"] == $old_data["password"];

         if (!$canlogin) {
            $msg = $GLOBALS["strUserExists"];
            $msg.= '



rem out the return statement at the end of the above block.

In the same file around line 370, find the following block;

   if ($blacklisted) {
      $thankyoupage .= '


      #return 1;

also rem out the return statement at the end of the above block.


23-04-10 16:02

administrator   ~0050961

I agree with the original issue, when re-subscribing with ask-for-password just take the details and resubscribe, and don't check with the password on file.