View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017850 | phpList 3 application | phpList | public | 30-09-15 17:28 | 16-01-19 09:46 |
| Reporter | nymisoa | ||||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| Product Version | 3.2.0 | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0017850: Remote Processing of Queue Logs Event Unnecessarily | ||||
| Description | Remote 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. | ||||
| Tags | No tags attached. | ||||
|
|
will check, thanks |
|
|
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? |
|
|
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. |
|
|
Still getting events logged. Now I'm not so sure the remote processing via cURL is working. |
|
|
can you do the calls without setting $_REQUEST['login'] and $_REQUEST['password'] Just /?page=processqueue&secret=XX should be enough |
|
|
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. |
|
|
output.html (1,625 bytes) |
|
|
I added the source html file with the output from the browser call I referenced above. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
Still an issue with v. 3.2.1. |
|
|
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. |
|
|
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. |
|
|
thanks |
