semoliner

Thanks, really appreciate your support, and have left a review. I’ll now close this thread.

Thanks, just one more thing – occasionally when attempting test purchases I got an error just called “undefined” in the red bar. I worked out that this correlated with my IP address having been blocked by our anti-spam plugin, because my VPN’s IP address range had been flagged as high risk, so the plugin blocked parsing of the form. I guess this is more of an observation than a question, but anyway does it make sense to you that this was cause the undefined error?

Hi, thanks, our SMTP is actually handled by our web host. But your comment made me remember that my VPN regularly changes my IP address, which I presume would explain the “Error! Page load signature check failed” error, assuming my IP address had changed in the time between initially accessing the page and clicking the Buy button? – a very likely scenario.

Hi,
I seem to have fixed it by ensuring that the ‘to’ and ‘from’ email addresses are now different. Funny that this was never an issue over the last year or more!

With regard to other issues: it won’t have been an email limit issue as we send so few emails per day. But yes, our web host did move us to a new server recently – could that also be (at least part of) the issue?

Additionally, while performing the testing I had several “Error! Page load signature check failed” errors. I read elsewhere here that this could be a caching issue, but deactivating our WP Super Cache plugin (and clearing cookies) did not help.

What did help was disconnecting from my VPN before performing subsequent tests. On reconnecting, the error reappeared. Do you have any ideas about why this could be causing this error?

Thanks for the prompt response – that was helpful. Turns out debug logging was already enabled, so I have extracted the parts of the log relating to the last two purchases.

According to the first troubleshooting step, I should be seeing, eg.
[05/11/2018 4:03 AM] – Notification email sent to buyer: etc

However, what I’m seeing is:
[07/04/2023 10:57:49 PM] – Notification email to buyer scheduled: [email protected], from email address used: Ku-ring-gai Historical Society [email protected]
[07/04/2023 10:57:49 PM] – Notification email to seller scheduled: [email protected],[email protected],[email protected], from email address used: Ku-ring-gai Historical Society [email protected]
[07/04/2023 10:57:49 PM] – Payment has been processed successfully.
[07/04/2023 10:57:49 PM] – Redirecting to results page “https://www.khs.org.au/stripe-checkout-result/”

So firstly, is it a concern that the emails were only ‘scheduled’, not ‘sent’?

And secondly, I’ve highlighted that one of the seller emails is the same as the sender “from email address used” – I note that from troubleshooting step #6)?Ensure the “to” and “from” email addresses are NOT the same
– but this has never actually been an issue before.

Thanks @jeherve

How do I disable this “override” for the automatic update of the Jetpack plugin? I am trying to trace the cause of an issue and the only way I can do that effectively is to revert back to the previous versions of all plugins that have updated over the last few days, monitor for whether the issue persists, and then update each plugin one-by-one over the coming days and monitor for the issue. Jetpack has stymied this process by overriding my settings. I can easily downgrade manually to the previous version again but it really doesn’t help when Jetpack will immediately reverse this process.

I’m no expert at all but it would seem to me that it would be quite trivial for someone to write a script that would trawl websites for login pages, and it wouldn’t matter what the ‘obfuscated’ URL might be, if it’s online it will be found.

If this is the case, then it doesn’t matter how many times you change your WPS Hide Login URL, eventually it may well be found by such a script.

All WPS Hide Login does is remove the possibility of the average person (without the aid of such a script) gaining access to your website via the default WordPress login URL.

I would be interested to hear if this is correct… or just my imagination?

I have posted here in this forum because someone discovered my WPS Hide Login page. The fact that they have not discovered it since I changed the page does not mean there is no problem, it just means no one has discovered the new page – yet.

Sorry but I really can’t describe it any clearer than in my last post.

The website does not have any option in General settings for “Everyone can sign up”.

There is an option called Membership “Anyone can register” and this is unchecked.

We do not have any comments section where users can reach the login page (in fact we don’t have any comments section at all).

There is no public login page, the only login page is the WPS Hide Login URL, which is only known to me. The link to it is not displayed anywhere in the theme.

So far I am unaware of any further attempts to hack the login since I changed the slug, but the original slug could not be guessed, so it should not have been necessary to change it, unless it can be derived by bots?

PS: I just read another thread “Website getting failed login attempts” in which the reply was “Robots crawl your pages and can find any link. If there’s a public link to your login page, this one is reachable by anyone.”

Is this the answer we have been seeking here?

Note that my WPS Hide Login slug has no published link but perhaps robots find it anyway?

Yes the browser cache was probably the cause of not being able to see the modified login page (I modified my post when I figured that out, I hoped you wouldn’t see it, ha!) so now the mystery is only how the would-be hacker found my original login page? Anyway now I’ve changed the login page and let’s see what happens.

This issue started happening for me too, I’m getting reports of failed login attempts at my WPS Hide Login login page, but no-one knows that page except me, so am I supposed to believe that someone just guessed it? It’s unlikely as it’s hard to guess!

They are trying to guess the pwd for the user ‘admin’ which I guess is pretty typical, but they won’t have luck because my site does not have a user by that name ??

Now I have changed the login page location in the plugin, and will monitor to see if the issue still presents itself.

I have not added any new plugins lately (but of course there have been updates) and I don’t use Cloudflare.

• This reply was modified 2 years, 1 month ago by semoliner.
• This reply was modified 2 years, 1 month ago by semoliner.

Thanks – I have set ‘Daily Transaction Limit with Captcha’ to 5 (we have never had more than 2 sales in one day, so I think this is sufficient).

I had to set ‘Daily Transaction Limit without Captcha’ to 1, because when I tried 0, I found it had defaulted to 25 after saving.

It would be nice to be able to set it to zero, but I imagine that setting is irrelevant anyway, since we have Captcha enabled?

Hi,

We also had a bot attack recently while using the Accept Stripe Payments plugin. I had been ‘diligently ignoring’ the warning that reCAPTCHA was not enabled, because we are using an anti-spam plugin (which will remain nameless) which specifically claims to obviate the need for CAPTCHA usage. I opened a support case with that plugin’s developer but they were unable to find out why it had failed in that manner.

So – lesson learnt the hard way – we now have reCAPTCHA v2 enabled, per the Accept Stripe Payments instructions!

I do have a followup question for @mra13 or @mbrsolution though – is is perfectly safe to have Google’s reCAPTCHA Security Preference set to the middle setting rather than to “Most Secure”?

Cheers, S.