View Issue Details

IDProjectCategoryView StatusLast Update
0017850phpList 3 applicationphpListpublic16-01-19 09:46
Reporternymisoa Assigned To 
Status resolvedResolutionunable to reproduce 
Product Version3.2.0 
Summary0017850: Remote Processing of Queue Logs Event Unnecessarily
DescriptionRemote processing of the Queue using the secret token works properly (even wonderfully) but it does log an event about an invalid login. I traced the problem to Line 254 of /lists/admin/index.php. This line (adds the "login problem" to the event log) should not execute if the $_REQUEST['secret'] variable is set.

TagsNo tags attached.



30-09-15 16:44

administrator   ~0056918

will check, thanks


01-10-15 09:25

administrator   ~0056926

I cannot replicate this. It may be that this was resolved with 0017839

The main thing is that you need to call the remote queue processing from a different system than your browser. You should not mix it with being logged in to phpList with the same browser.
Could that be the case? How are you activating the remote queue?


02-10-15 14:51

reporter   ~0056932

I patched my setup with the fix you mentioned.

I activate the remote queue from a cron job which runs a php script. The script runs a simple cURL call to the processqueue URL. The cron runs every hour and an even is logged every time it runs.

The event logged is "invalid login from (server IP redacted), tried logging in as cron".

What's interesting here is that $_REQUEST['login'] and $_REQUEST['password'] have to be set in order for the event to be logged. Based on the event, $_REQUEST['login'] is set to 'cron' and $_REQUEST['password'] is being set with a string. I'm not passing either of these in the cURL call so they are getting set somehow.

I'm going to add a conditional to check for $_GET['secret'] and see if the event is logged.


02-10-15 15:19

reporter   ~0056933

Still getting events logged. Now I'm not so sure the remote processing via cURL is working.


02-10-15 15:21

administrator   ~0056934

can you do the calls without setting

 $_REQUEST['login'] and $_REQUEST['password']

Just /?page=processqueue&secret=XX should be enough


02-10-15 15:47

reporter   ~0056935

I've been doing the cURL calls with just setting the page and secret.

I've tried to troubleshoot using a browser that's not logged into phplist and running the php script in the browser (rather than running it as cron). It was outputting the login page which leads me to believe that the queue was not processed. The output from outputCounters() was not returned either which was troubling.

So I added a conditional which would bypass the 'requirelogin' process where $_GET['secret'] was set. The good news here is that I did get the output from outputCounters() (which is a nice json so thank you) but there was a bunch of rogue html that preceded it. Optimally, when processing the queue remotely, only the json should be retuned.

I'll keep working on this.

Thanks for all you do.


02-10-15 15:54


output.html (1,625 bytes)   

<!---->	    </div>
    </div> <!-- end #content -->

    <div id="right-bar" class="grid_4 four columns">
            <div id="context-menu" class="menutableright block">
            <ul class="contextmenu"><li class="shade0"><a href="./?page=home&amp;tk=f354" title="Go to the dashboard page">Dashboard</a><br /></li><li class="shade0"><a href="./?page=about&amp;tk=f354" title="More information about the phpList application">about phpList</a><br /></li></ul>        </div>
        <div id="recent" class="menutableright block">
	    <div id="language">
	<div class="clear"></div>
	</div><!-- end #right-bar -->
	<div class="clear"></div>

</div> <!-- end #container -->

<div id="footer">
    <div class="container">
            <a target="_blank" href="">&copy; phpList ltd.</a> - v3.2.0        <div class="right">
            <a target="_blank" href="">Resources</a>&nbsp; |  
            <a target="_blank" href=""><img src="ui/dressprow/images/twitter.png" alt="phpList twitter" /></a>
<script language="Javascript" type="text/javascript" src="ui/dressprow/js/all.min.js?v=1426017467"></script>

</body></html>{"campaign":0,"num_users_for_message":0,"batch_count":0,"batch_total":200,"sendemail returned false total":0,"send blocked by domain throttle":0,"add attachment error":0,"sendemail returned false":0,"sentastest":0,"invalid":0,"failed_sent":0,"sent":0,"num_per_batch":200,"status":"embargo","delaysend":null}
output.html (1,625 bytes)   


02-10-15 15:56

reporter   ~0056936

I added the source html file with the output from the browser call I referenced above.


02-10-15 15:58

administrator   ~0056937

hmm, how odd. Yes, indeed, the idea is that only the JSON data is returned.

Can you apply this patch as well? Just to be sure. And then make sure to define SHOW_PQCHOICE as false


02-10-15 16:50

reporter   ~0056939

Confirmed the patch was installed as directed.

I found the rogue html in the debugging section of the file so I put a conditional on that to check for $_GET['secret'] so it doesn't output when remote processing.

I'm still getting the event logged when running from cron but I can't find anywhere in the package where that event would be logged other than lists/admin/index.php.


05-10-15 16:01

reporter   ~0056958

I should add that this event is logged when the queue is empty. I've been looking at the processQueueOutput() to see if that could be logging the event.


05-10-15 22:16

reporter   ~0056963

Still an issue with v. 3.2.1.


09-10-15 14:14

reporter   ~0057007

More info on this.

When there is a message in the queue and the queue is processed using the cURL call and secret token, the message is processed properly with no logging of any events related to the queue being processed. However, this login failure event is logged.

I looked through the code again and it appears that all event logging is suppressed with the queue is processed using this technique so suppressed logging is intended. Still can't track the logged event regarding the invalid login.


14-10-15 14:05

reporter   ~0057031

Please close this ticket. There is no bug.

The events are coming from an old cron job I had three servers ago on an account that's long since been terminated. Or so I thought.


14-10-15 14:14

administrator   ~0057032