captaincrank
Forum Replies Created
-
Forum: Plugins
In reply to: [WooCommerce] 10.8.0 Update ErrorWhat I did was restore the prior version of WC from my server then updated to 10.8.0 again and had no errors. All appears to be working well at the moment.
I’ve noticed on our packing slips the user field is now empty whereas it used to have the customer’s email. I wonder if that may also be related to your problem?
Next time we encounter the problem I will try to get more info. We just ran a small batch of 4 orders, and it worked fine.
Forum: Plugins
In reply to: [WooCommerce] Security Concern: Direct Add-to-Cart GET Requests VulnerabilityThese add to cart hits will likely get worse with agentic shopping. We saw Google doing it themselves which suggests they may be testing their own shopping agent with our store.
The problem with shopping agents is that it will allow customers to bypass our detailed instructions, terms they agree to during checkout, etc. This will lead to increased liability for the types of products we sell and therefore is a violation of our terms. Since the customer will not see our terms and Google could care less because they have full product liability immunity to do as they please, the increased liability, increased returns and cost of shopping agents gets unloaded onto us sellers.
Forum: Plugins
In reply to: [WooCommerce] Problems Giving Perplexity Credit for the Origin of Sales?Thanks for the detailed response. Fortunately we can track with our own analytics, but having the origin in the backend can be useful at a glance for those who process orders without analytics access. As a matter of principal, with Google stealing our content and traffic, we have removed all Google spyware from our site.
Forum: Plugins
In reply to: [WooCommerce] Any Plans to Support OpenAI Like Shopify, Etsy, etc.?I want to assure you that our developers at WooCommerce are actively looking into integrating this AI-driven commerce.
Great to hear! We use both Stripe and Paypal payments from WC.
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Card Testing Attacks, Fix Coming?Now we’re getting attacked. I hope a fix gets expedited before this grows to an intolerable level. Security of any plugin MUST always be a top priority, and I’d like to see WC treat it as such.
Just wanted to confirm updating to version 3.0.9, and resubscribing hooks, resolved my errors.
Thank you for fixing this issue in the newest release. Have a good weekend.
Install Checkout Rate Limiter https://github.com/brianhenryie/bh-wc-checkout-rate-limiter/ to severely throttle such attacks.
Forum: Plugins
In reply to: [Rate limiting UI for WooCommerce] A Way to Curb Carding Attacks?We use a plugin called Checkout Rate Limiter to prevent carding attacks. Though it hasn’t been updated in a while, it works great and logs attacks it has stopped. Settings allow configurable time limit blocks for the first, second and third attempts which should work for you. See https://github.com/brianhenryie/bh-wc-checkout-rate-limiter/ for details.
Forum: Plugins
In reply to: [WooCommerce] Emails Changed and Logo is So Small!For whatever reason our logo in global settings was changed to 120 pixels wide when we updated WC. Hopefully updating WC didn’t change anything else!
I consider this issue resolved.
I asked Siteground to permanently whitelist the IP addresses, and below is the response I received. I added this response to my Ship Station support ticket as well.
I’m not confident our problem will be permanently resolved. What we really need is the ability to control SGcaptcha use, whitelisting, etc. within our accounts and preferably on a domain level. We’re on a GoGeek plan, which like all their WordPress plans, is supposed to be Woocommerce enabled. Frustrating to say the least…
I believe your hunch was right about Siteground being responsible with their SGcaptcha. Go to settings > store setup > edit store details > activity. In that log I found the following (session data SNIPPED):
Shipstation
An error occurred attempting to update orders: Invalid XML. Error: ''=' is an unexpected token. The expected token is ';'. Line 1, position 297.' We received: '<html><head><link rel="icon" href="data:;"><meta http-equiv="refresh" content="0;/.well-known/sgcaptcha/?r=%SNIPPED-api%3Dwc_shipstation%26auth_key%SNIPPED-SNIPPPED'Unfortunately Ship Station error notices for this are not appearing at the top of the screen where they normally appear and are highly visible – making the errors hidden until digging into Ship Station’s logs.
I created a case with Ship Station requesting all IP addresses they use so I could give to Siteground to whitelist. I also created a case with Siteground which was forwarded to their security team for their review. SG responded quickly and they were able to locate the suspect IP addresses. This is the response I got:
Checking the situation, I found two of the listed IPs to be restricted:
35.173.55.253
52.203.135.90
The reason for this is that they made POST requests to the default virtual host (vhost) on a different SiteGround server. This is why the IP addresses were challenged by our CAPTCHA. For your convenience, I removed the restriction on the two IPs, but please keep in mind that if erroneous post requests are made in the future, they may get restricted again.It would appear some have a misconfiguration installed on a different server that is causing errors and SG has decided to block IP addresses across the board. Anyway, this is as far as I got. Hopefully this is resolved, but I have a hunch it will happen again until either SG whitelists the IP addresses permanently and/or they suspend the account(s) triggering these IP blocks. Now that we know what’s going on, if it happens again we can create support tickets with SG and reference this thread. Anyway, I hope this info helps you and hopefully resolves both our problems.
I forgot to mention, product thumbnails do not always load in Ship Station now as well. This may potentially be related to the intermittent problems with WC not receiving shipment notifications from Ship Station.
Below is what I have, but those are old and not current since we’re not blocking AWS anymore. Ship Station could have started using another provider, but as I’ve said before I don’t see any errors on the server to suggest they are being blocked at the server. If it were blocked, even by SG’s own firewall, the communication error would be present in Ship Station, and it’s not.
34.200.1.155
34.199.251.255
52.203.135.90
34.200.10.239
18.211.231.40
35.173.55.253You may be onto something…
We are on Siteground as well. Might be them blocking the IP address at the router level which is why we don’t see anything in our log files? We need to get a current list of IP addresses used by Ship Station and get that over to Siteground for them to check. However, we did block AWS ranges (which Ship Station used in the past) in the past, and there was an error inside Ship Station. If Siteground were blocking 1+ Ship Station IP addresses, we still should see the communication error when we login to Ship Station.