dev
Forum Replies Created
-
Hello,
So few updates on this and thank you for taking a look.
We’ve removed the no captcha plugin and have in test mode the wordfence one. Previously the WF one broke the sites login when being used in a multisite setup. This now appears to be working (The site is now standalone, not a subsite) as expected but will enable properly after further testing.
We’ve recently moved hosting to kinsta and the attacker has stopped using the vuln non-captcha reg form and started with the standard woocommerce form.
The issue with the traffic not being blocked properly was determined to be being caused by the kinsta cache. Wordfence would block the IP but they could still access pages cached by kinsta. Access.logs in kinsta show a 503 from cloudflare but then can still GET/POST to the my-account page. We’ve sent them new cache bypass details and are waiting on test results. Because the attacker has been using a botnet out of a VPN service for the last 1-2 months the IPS are always changing. Kinstas own security only allows per IP blocking and we have no control over their WAF or other firewall rules.
We’ve also managed also to put a cloudflare JS challenge, within our own CF account, on these pages which has stopped further accounts being made. The next step is to switch from this to the wordfence captcha. V3 however, using multiple other captcha plugins, was problematic when a challenge was prompted as the prompt did not show and the complianz GDPR cookie plugin broke the captcha often. This could be due to our site not showing the captcha prompt when being triggered or the above complainz issue.
I’ll report back here in a few days once we’ve carried out the next testing steps.
Thanks again.
Apologies, it seems debug.log didn’t enable so the old logs were sent over by mistake. This was an issue our end.
I’ve manually checked and I can see changes on older than 30+ orders. V4 was run however no updated logs.
I’ll rebuild a test site and rerun again.
Having the same list of 10x order loops in a single debug.log is new and something isn’t working in the V4 of the script.
V4 appears to fix the first 10 orders (then loops back and breaks) but v3 runs for all of the orders.
Just to confirm, the cloned sites are new each time so as is needed above to perform a new test.
Unfortunately this is with version 4. The previous versions log output was different, so you can tell it’s the version 4 of the script.
I’ve taken an exact clone of the broken site and reran the latest each time.
Doesn’t work as of yet however is nearly there.
It does a first load of orders and does appear to fix them. However it then loops back and tries to redo the same orders but then breaks and stops with no proper logs.
Sent the whole load via the contact form.
So some progress, it now processes all orders. However it has incorrectly marked all of the disconnected orders as guest purchases when a user account exists with the same email billing has.
We cleared up and removed all failed orders over the last 2 years so all are completed orders.
[09-Feb-2022 12:16:56 UTC] DONE PROCESSING 5 ORDERS - WE GO TO THE NEXT 5 ORDERS... [09-Feb-2022 12:16:56 UTC] NO MORE ORDERS TO PROCESSED. [09-Feb-2022 12:16:56 UTC] DONE PROCESSING ALL WOOCOMMERCE ORDERS. [09-Feb-2022 12:16:56 UTC] THERE ARE AROUND 1620 ORDERS PROCESSED. [09-Feb-2022 12:16:56 UTC] DEACTIVATING HOTFIX PLUGIN SCRIPT...Order #9588 for example has a user account with the billing email. Log shows:
[09-Feb-2022 12:16:51 UTC] ORDER ID: 9588
[09-Feb-2022 12:16:51 UTC] ORDER ID: 9588 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASEThe latest script is marking all orders as guest, luckily this was in staging.
[09-Feb-2022 12:16:51 UTC] ORDER ID: 9630 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] DONE PROCESSING 5 ORDERS - WE GO TO THE NEXT 5 ORDERS... [09-Feb-2022 12:16:51 UTC] Processing 5 orders for page 7 [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9629 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9629 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9628 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9628 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9606 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9606 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9604 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9604 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9603 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9603 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] DONE PROCESSING 5 ORDERS - WE GO TO THE NEXT 5 ORDERS... [09-Feb-2022 12:16:51 UTC] Processing 5 orders for page 8 [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9601 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9601 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9600 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9600 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9599 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9599 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9588 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9588 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9584 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9584 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] DONE PROCESSING 5 ORDERS - WE GO TO THE NEXT 5 ORDERS... [09-Feb-2022 12:16:51 UTC] Processing 5 orders for page 9 [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9580 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9580 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9576 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9576 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9575 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9575 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9574 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9574 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] PROCESSING ORDER [09-Feb-2022 12:16:51 UTC] ORDER ID: 9569 [09-Feb-2022 12:16:51 UTC] ORDER ID: 9569 IS ASSOCIATED WITH GUEST PURCHASE, _customer_user = 0. UPDATING DATABASE [09-Feb-2022 12:16:51 UTC] DONE PROCESSING 5 ORDERS - WE GO TO THE NEXT 5 ORDERS...I’ve re-activated the plugin and the results are the same. It runs though the 10 most recent and stop.
I made reduced the lines of code just to log the order IDS within debug.log
and the result was this
[08-Feb-2022 16:43:38 UTC] Retrieving all orders [08-Feb-2022 16:43:38 UTC] Processing order [08-Feb-2022 16:43:38 UTC] ORDER ID: 9761 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9743 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9694 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9692 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9691 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9690 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9689 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9687 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9685 [08-Feb-2022 16:43:38 UTC] ORDER ID: 9684 [08-Feb-2022 16:43:38 UTC] DONE PROCESSINGFor some reason, this code is only getting the last 10:
$orders = wc_get_orders( $args ); primeMoverWriteLog("Processing order"); foreach ($orders as $order) { $order_id = $order->get_id(); primeMoverWriteLog("ORDER ID: $order_id"); }Because of the data in it, there is no way to sanitize it for data protection or scrub non relevant data.
Would the migration logs, specific to [user_equivalence] => SplFixedArray Object, help once redacted?
There are about 1700 orders, the plugin stops at the second guest (not first) so something isn’t working as expected.
I’ve sent the full log as requested, but the plugin as of the moment is not working. It gets to the second problematic order and then stops E.G:
[08-Feb-2022 14:54:28 UTC] ORDER ID: 9687 [08-Feb-2022 14:54:28 UTC] BILLING EMAIL: <<redacted>> [08-Feb-2022 14:54:28 UTC] ORIGINAL CUSTOMER ID: 505 [08-Feb-2022 14:54:28 UTC] GET USER INFO BY BILLING EMAIL. [08-Feb-2022 14:54:28 UTC] MIGRATED USER ID: 505 [08-Feb-2022 14:54:28 UTC] MIGRATED USER ID IS ALREADY THE SAME WITH CUSTOMER ID. [08-Feb-2022 14:54:28 UTC] ORDER ID: 9685 [08-Feb-2022 14:54:28 UTC] BILLING EMAIL: <<redacted>> [08-Feb-2022 14:54:28 UTC] ORIGINAL CUSTOMER ID: 0 [08-Feb-2022 14:54:28 UTC] GET USER INFO BY BILLING EMAIL. [08-Feb-2022 14:54:28 UTC] NO USER ASSOCIATED WITH THIS BILLING EMAIL, BAIL OUT DONT PROCESS. [08-Feb-2022 14:54:28 UTC] ORDER ID: 9684 [08-Feb-2022 14:54:28 UTC] BILLING EMAIL: <<redacted>> [08-Feb-2022 14:54:28 UTC] ORIGINAL CUSTOMER ID: 0 [08-Feb-2022 14:54:28 UTC] GET USER INFO BY BILLING EMAIL. [08-Feb-2022 14:54:28 UTC] NO USER ASSOCIATED WITH THIS BILLING EMAIL, BAIL OUT DONT PROCESS. [08-Feb-2022 14:54:28 UTC] DONE PROCESSING- This reply was modified 4 years, 4 months ago by dev.
Awesome, thanks again 🙂
Ok so the logging shows the plugin works past the ones we have manually set, however the first order it fails and then stops processing. Here is the redacted one, let me know if you still need the full log.
[08-Feb-2022 14:54:28 UTC] NO USER ASSOCIATED WITH THIS BILLING EMAIL, BAIL OUT DONT PROCESS. [08-Feb-2022 14:54:28 UTC] ORDER ID: 9684 [08-Feb-2022 14:54:28 UTC] BILLING EMAIL: <<Redacted>> [08-Feb-2022 14:54:28 UTC] ORIGINAL CUSTOMER ID: 0 [08-Feb-2022 14:54:28 UTC] GET USER INFO BY BILLING EMAIL. [08-Feb-2022 14:54:28 UTC] NO USER ASSOCIATED WITH THIS BILLING EMAIL, BAIL OUT DONT PROCESS. [08-Feb-2022 14:54:28 UTC] DONE PROCESSINGI’ve checked this order and it was purchased as a guest. So it looks like the plugin needs some code to detect/handle and skip guest purchases, then it should be ok?
I’ve run the cron manually and it removed around 430 records, which is great!
There are still a lot of eael_updated_at however.
Many thanks
Hello,
I’ve installed the dev version on one of ours sites and disabled auto-updates.
Can be start the cron job now or do we need to wait for other backend processes?
Many thanks!
Hello,
Thanks for getting back to me.
The plugin just activates instantly. Is there a way to debug this or get a log written ? It doesn’t seem to run.
Many Thanks !