|
Digital Services Lab
|
January 31, 2024 at 6:50 pm
When on the Registrations – Overview page, there are several view options at the top.
- View All…
- This Month
- Today
- ..etc
When on the View All options the Registration CSV Report works fine and downloads as expected.
When on any of the other view options, the report does not work. Instead a 404 message is received.
I’ve attached the query parameters for the successful report and the failed report below in case there is some issue visible there. (domain and nonce removed)
The only difference I see is the return url and then obviously the filters.
Query String Parameters
page: espresso_batch
batch: file
filters: a:5:{i:0;a:1:{s:6:"STS_ID";a:2:{i:0;s:2:"!=";i:1;s:3:"RIC";}}s:4:"caps";s:10:"read_admin";s:24:"default_where_conditions";s:15:"this_model_only";s:8:"order_by";a:2:{s:8:"REG_date";s:4:"DESC";s:6:"REG_ID";s:4:"DESC";}s:5:"limit";a:2:{i:0;i:0;i:1;i:10;}}
use_filters
job_handler: EventEspresso\core\libraries\batch\JobHandlers\RegistrationsReport
return_url: /wp-admin/admin.php?page=espresso_registrations
action: default
default_nonce: xxx
return: registrations_report
Query String Parameters
page: espresso_batch
batch: file
filters: a:5:{i:0;a:2:{s:6:"STS_ID";a:2:{i:0;s:2:"!=";i:1;s:3:"RIC";}s:8:"REG_date";a:2:{i:0;s:7:"BETWEEN";i:1;a:2:{i:0;O:49:"EventEspresso\core\domain\entities\DbSafeDateTime":1:{s:19:"*_datetime_string";s:42:"2024-02-01 00:00:00 +1100 Australia/Sydney";}i:1;O:49:"EventEspresso\core\domain\entities\DbSafeDateTime":1:{s:19:"*_datetime_string";s:42:"2024-02-29 23:59:59 +1100 Australia/Sydney";}}}}s:4:"caps";s:10:"read_admin";s:24:"default_where_conditions";s:15:"this_model_only";s:8:"order_by";a:2:{s:8:"REG_date";s:4:"DESC";s:6:"REG_ID";s:4:"DESC";}s:5:"limit";a:2:{i:0;i:0;i:1;i:10;}}
use_filters: 1
job_handler: EventEspresso\core\libraries\batch\JobHandlers\RegistrationsReport
return_url: /wp-admin/admin.php?page=espresso_registrations&action=default&default_nonce=xxx&status=month
action: default
default_nonce: xxx
return: registrations_report
|
|
Tony
|
February 1, 2024 at 5:29 pm
Hi there,
Strange! Generally if you get a 403 on export I’d recommend checking your sites permissions to confirm you can write to /wp-content/uploads/espresso/, however both those exports work in the same way (in terms of writing to files) so I’d expect both not too work.
It could be that the filtered requests are triggering a mod_sec rule on the server.
Any errors in the error logs when trying to run these exports at all?
|
|
Digital Services Lab
|
February 4, 2024 at 4:36 pm
No there are no errors in either the WP debug log or the php error log. A couple of deprecation warnings but that’s it and they are from other plugins.
|
|
Tony
|
February 5, 2024 at 5:58 am
Try adding this to your sites PHP config file:
define( 'EE_USE_OLD_CSV_REPORT_CLASS', true );
Its not a fix for the above, it switches to the ‘old’ system for exporting registration and I’m checking to see if the request within that works.
Right now I suspect this is mod_sec on your server blocking the request.
You’ve posted both 403 and 404 error codes in this thread, I assume both should be 403?
|
|
Digital Services Lab
|
February 5, 2024 at 3:42 pm
Hi Tony,
I’ve tested it with the variable above and it works.
So what does that mean? why would mod_sec block a request to the same resource just because it’s filtered in one instance. It doesn’t make sense.
Yes, it’s a 403 message. I’ve mentioned before that it’s quite limiting not being able to edit messages on this forum… it makes it impossible to update a message to correct errors or add clarity.
|
|
Tony
|
February 5, 2024 at 3:56 pm
So what does that mean? why would mod_sec block a request to the same resource just because it’s filtered in one instance. It doesn’t make sense.
It may not make sense right now, but I’ve seen much weird goings on with overreaching mod_sec rules.
The filtered request has a much longer query string which can trigger mod_sec, or some rule set just doesn’t like the the contents of the request.
With the above constant still in place, manually apply a filter (say, filter Approved registrations) and export, still work?
(The ‘old’ system exports all of the registrations in a single request, the new system batch processes those requests)
Yes, it’s a 403 message. I’ve mentioned before that it’s quite limiting not being able to edit messages on this forum… it makes it impossible to update a message to correct errors or add clarity.
I understand it can be frustrating but the edits also add much more complexity/confusion when users go back and completely change questions after the fact which then throws answers out of whack (yes, it’s happened 🙂 ) So not being able to edit posts is the lesser of 2 evils here.
|
|
Digital Services Lab
|
February 5, 2024 at 4:05 pm
hmm well I am unable to filter the registration status with or without that constant in place. I am getting the red banner at the top with the following error message.
An error has occurred:
Something went wrong, and the status was not changed
Registrations_Admin_Page - 1788 - _reg_status_change_return
|
|
Tony
|
February 5, 2024 at 4:27 pm
So you’re going to Event Espresso -> Registrations.
Changing the Reg Status dropdown to Approved and hitting filter? Like this:
https://monosnap.com/file/j2XCh62UjGsjUw8gBgG18bQ3PLeWDi
|
|
Digital Services Lab
|
February 5, 2024 at 4:30 pm
oh sorry, no I was doing something dumb.
Yes, that still works.
|
|
Tony
|
February 5, 2024 at 4:50 pm
I can’t think of anything else that would give you a 403 on those requests.
I recommend opening a ticket with your host and having them confirm if the requests are being blocked on their end.
We’ve not had any other reports of this, I can’t reproduce this on any of my test site (I run many on various different types of hosting) and the batch processing of CSV requests (filtered or not) has been included within core for a while now.
Personally, my next step in testing this would be clone the site locally and see if the export run there, if it does you know its likely some kind of server config issue.
|
|
Digital Services Lab
|
February 5, 2024 at 4:53 pm
Thanks. I’ve already opened a ticket with the host. I am waiting for a response.
I will do some further troubleshooting on a dev site.
|
|
Tony
|
February 5, 2024 at 5:04 pm
Actually, another option for troubleshooting (try it on dev) is to use the Health Check & Troubleshooting plugin:
https://wordpress.org/plugins/health-check/
Then go to Tools -> Site Health -> Troubleshooting and enable it.
That switches to a default theme and disables all plugins but just for you the logged-in admin.
Enable Event Espresso and see if the export works.
If it does, work through enabling each of your plugins one by one and run an export between each on until it breaks (if it does) to narrow down a plugin conflict.
When finished go to the Admin bar and Troubleshooting -> Disable Troubleshooting
(If working on dev you can also do the above directly without the Health Check plugin)
|
|
Digital Services Lab
|
February 5, 2024 at 5:04 pm
Tony, I’ve found that the mod_sec rule triggering the 403 error is rule 933170 which blocks
#
# [ PHP Object Injection ]
#
# PHP Object Injection is an application level vulnerability that could allow
# an attacker to perform different kinds of malicious attacks, such as
# Code Injection, SQL Injection, Path Traversal and Application Denial of Service,
# depending on the context.
#
# The vulnerability occurs when user-supplied input is not properly sanitized
# before being passed to the unserialize() PHP function. Since PHP allows object
# serialization, attackers could pass ad-hoc serialized strings to a vulnerable
# unserialize() call, resulting in an arbitrary PHP object(s) injection into the
# application scope.
Which explains why its only blocking the filtered requests since they contain a serialised array of filters….
|
|
Digital Services Lab
|
February 5, 2024 at 5:16 pm
So while this error will only occur for users who have this rule set, it is an important rule and I would argue that it’s the code causing the issue here since it is a vulnerability that should not exist within the code.
OWASP prevention technique for this vulernablity is simple:
“Do not use unserialize() function with user-supplied input, use JSON functions instead.”
https://owasp.org/
|
|
Tony
|
February 13, 2024 at 6:26 pm
Hi there,
I’ve created an issue for our developers to discuss this.
In the meantime, you will need to either disable the above rule, or add/leave:
define( 'EE_USE_OLD_CSV_REPORT_CLASS', true );
Set within wp-config.php to use exports with batch processing to run the exports.
|
