View Issue Details

IDProjectCategoryView StatusLast Update
0017850phpList 3 applicationphpListpublic14-10-15 14:14
Reporternymisoa 
PrioritylowSeverityminorReproducibilityalways
Status resolvedResolutionunable to reproduce 
Product Version3.2.0 
Target Versionnext patchFixed in Version 
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.

Activities

michiel

30-09-15 16:44

manager   ~0056918

will check, thanks

michiel

01-10-15 09:25

manager   ~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?

nymisoa

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.

nymisoa

02-10-15 15:19

reporter   ~0056933

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

michiel

02-10-15 15:21

manager   ~0056934

can you do the calls without setting

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

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

nymisoa

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.

nymisoa

02-10-15 15:54

reporter  

output.html (1,625 bytes)

nymisoa

02-10-15 15:56

reporter   ~0056936

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

michiel

02-10-15 15:58

manager   ~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

https://github.com/phpList/phplist3/commit/80eb2a02995d4e0d8e5570b7208e1ae20b673f8e

nymisoa

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.

nymisoa

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.

nymisoa

05-10-15 22:16

reporter   ~0056963

Still an issue with v. 3.2.1.

nymisoa

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.

nymisoa

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.

michiel

14-10-15 14:14

manager   ~0057032

thanks