Jelena
Forum Replies Created
-
Hi,
Firstly, many thanks for upgrading your review. Much appreciated.
Here is a small clarification on the auto block expiration timeout you may find helpful:
If the blocked IP accesses your site within 24hrs period of time, we update the last access time and the 24hrs counter resets and starts again from zero. If they come back and try to access the site again, they’ll get blocked. Again. This ensures that a given visitor stays blocked.They must wait 24hrs before trying to access the site again. Once an IP address entry has expired and that IP hasn’t attempted to access the site again within the 24hrs timeout period, the daily WordPress Cron will clean it out from the table and IP will be unblocked.
We suggest decreasing the timeout to 1hour while you are testing.
The reason it probably didn’t work before was because of the “High Reputation Bypass” setting (detailed here) that prevents high reputation IPs from being blocked. So, this option prevents your legit site visitors with a high Reputation Scores from being blocked.
Imagine it this way: Shield will monitor everything your IP does, and it’ll mark offenses against it. Once the IP has accumulated enough offenses and it’s about to block your IP address, it’ll lookup your Bot Reputation Score and if it’s high enough, you wont be blocked.
If you’ve got any thoughts or questions, feel free to leave a WordPress forum topic for us. It’s a much easier to all of us to chat and sort things out there than in the review section.
We also highly appreciate any bug reports. If you spot it, please share it on forum or reach out to us directly any time and we’d be happy to work on it with you.
Regards and thanks for using Shield. 🙂
Jelena
Hi,
You can try disabling User Session Lock options detailed here.
Let us know how that works for you.
Thanks,
Jelena
Hi,
Sorry to hear about the troubles you are having with this.
Can you re-enable Shield, reproduce the problem and then:
Check the Activity Log detailed here… are there any notices coming up in there about blocks? Once you have this, then we can help out with what might need to be adjusted.
The Activity Log is the best place to look first for anything being blocked as it’ll tell you precisely what’s happening.
Let us know what you find in there.
Thanks,
Jelena
Hi,
Yes, this option is still there (under the Firewall > Firewall Response).
Can you check your Activity Log to see if there were any Firewall block logs in there, please? You can filter by “Firewall Block” events.
If there are such events and you have firewall email alert option enabled but you are not getting these emails, than the problem is likely with email delivery.
Unfortunately, this is a common issue we see very day…
Shield wouldn’t affect the sending/receiving of emails. Whether or not emails gets send from your site are entirely out of Shield’s control and sending is never interrupted by Shield. It’s important to take full control of email sending on a WordPress and not rely on WordPress itself to send emails via your web server.
Please review your email provider settings and ensure that it’s configured properly.Some email providers have gotten more strict with their email delivery you should know about:
https://convertkit.com/resources/blog/new-google-yahoo-email-rules-2024Hope you find this helpful in some way.
Jelena
No problem, happy to help. 🙂
Hi,
Sorry to hear that.
This could be caused by a new Shield’s v19.0 “User Session Lock” feature.
But to be sure, this is what we recommend:
- Reproduce logging out
- Use a forceoff method outlined here
- Log into your site
- Go to your Activity Log and filter logs by your IP address or username.
- Review logs. Hopefully, these will tell you why you’re logging out so you can change Shield settings to prevent it from happening again.
Let us know how you get on.
No problem, happy to help.
Cheers!
Hi,
Thanks for using Shield Security. 🙂
Regarding this error, this is the temporary directory as it’s used by the plugin & theme scanner and various other purposes in the plugin. Shield tries to find a temporary directory to use to write some temporary data.
/tmp is a last resort and if you’re getting errors about this it means Shield can’t write to anywhere in your wp-content directory.If you don’t want these errors, please make sure WordPress can write to either /wp-content/shield/ or /wp-content/uploads/ or /wp-content/cache.
As you can imagine, ensuring that creating temporary directories for every type of web host works can be tricky. While /wp-content/tmp/ might exist on your server, it may not exist elsewhere. It appears your filesystem permissions are setup such that creating our own /wp-content/shield/ directory fails, and so you’re getting these errors.
It would be good if you could set the filesystem permissions on that directory to allow WordPress to read/write to it because completely restricting disk-write entirely will prevent Shield functionality. Best is to chat with your host about your options. It’s very common for WordPress plugins to use temporary directories, so your webhost will need to provide the ability to do that.
Hope this helps.
Hi,
Sorry to hear that.
Under the main Config menu > Lockdown section, have you tried to disable the following options?:
- Disable XML-RPC
- Anonymous Rest API
If that doesn’t help, can you check your site admin email inbox and send us the error details, please? When a critical error occurs, WordPress sends email with error details. Email subject is “Your Site is Experiencing a Technical Issue”.
If you haven’t received it, please reproduce the error and then open up and review the web Console and/or Network tab (for AJAX/XHR requests). You may see errors there. This suggests something is going wrong with the request and there are errors being generated for some reason. The console will help highlight why this is happening, but then it may need investigation of PHP error logs to see what’s going wrong. Please check your PHP/Apache error logs. Once you can see the errors, we can probably point to the source of the issue quickly.
Let us know what you find especially if you see error logs and entries around the time the problem occurred and we’ll help however we can.
Thanks.
Thanks for the update. Happy to hear that you managed to sort it out.
The truth is, we get many support requests from site admins because a Shield feature isn’t working properly or site is acting strange and 9 times out of 10 it’s because of some sort of WordPress auto-optimisation – caching.
We have a list of rules here you can implement for your site optimisation.
If you decide using cache, ensure the site works as expected without caching. Then add caching last. If it breaks, try another caching solution. Caching should be the last thing enabled, and the first thing turned-off when there are problems.Hi,
Can you reproduce the problem and then immediately check your activity log, please? If Shield is causing the block, hopefully the activity log will tell us the type of the block and based on that, you can tweak the related settings. You may use this glossary here.
If there’s nothing in there, the next thing to check is page cache. If you use page cache plugin or server-level cache, please disable it and retry to see if the problem is solved.
Let us know what you find sure.
Thanks.
Hi,
Shield has special handling in there for all major search engines so that if they ever try to access your site in any way, Shield will never stop them – they’re basically whitelisted.
Shield doesn’t issue 403 errors. It’s possible it might interfere, somehow, so we never rule it out, but it doesn’t sound like.
Have you checked for changes to your .htaccess and robots.txt?
If you disable Shield, does the google fetch work?
Thanks.
Hi,
Thanks for your questions.
Shield Security provides solid login security protection for WordPress sites. It effectively thwarts brute force login attempts through simple, non-intrusive methods while ensuring the verification of all logged-in users. Many of Shield’s features are available for free. However, some advanced ones are reserved for the Pro version, as these help support the ongoing development of Shield.
Regarding email-based 2FA, you can’t disable it for your user profile because, based on your settings, you are enforced to use it.
If you don’t want to use it, you want to disable it for your profile completely, you’ll need to remove “administrator” user role from the 2FA settings. If you’d like to have the ability to choose to use it or not, you’ll need Pro option. So,
- Enforce for Specific User Roles: This is based on user roles. You can require certain user roles to use 2FA by email. Users with the roles specified on the list in settings won’t have the option to disable it from their profile. They must use it for their login.
2. 2FA-Allow Any User (Pro): Based on user account (username).
Users with roles not specified in the first option can choose to use 2FA by email or not. These users will not be enforced to use it. They can disable or enable it on their user profile, whatever they prefer.Google Auth is based on user account (username) and it’s optional option.
It is separate option and not connected to the 2FA by email in any way.
User can’t be enforced to use it for their login thought this is on our feature roadmap for future releases. When you turn on Google Auth system in settings, the all users regardless of their roles can decide if they want to use it or not. The configuration settings will be available on their user Profile.Since you’re running Shield Free, you can
- 2FA by email: Choose user roles you want to must-use this option. List those roles on the Enforce-Email Authentication list.
- The user roles that are not on the list will have 2FA by email disabled – not available on their user Profile at all. They will not be required to verify their login with 2FA by email and can use Google Auth only instead. But, you can’t enforce them to use Google Auth, it’s optional.
Users (user roles) that are enforced for 2FA by email, can also add an extra Google Auth layer.
Hope this helps…
Regards,
Jelena
Hi,
Just would like to share an update with you:
We’ve tested possible 2FA conflict with Wordfence, and we can’t reproduce 502 bad gateway error or see any other type of error…
Perhaps it’s something else on your site that’s causing this, or something particular to your hosting. Worth of investigating to see if that’s the case.Thanks for reporting this.
We’ll investigate the issue with resetting options – there may be a bug there. Could you let us know if you are deactivating from inside WP, or using FTP to remove the plugin?Also, which settings were kept when you tried to reset, please?
Shield has some default settings so maybe it is that you’re seeing?Can you try the “reset” feature detailed here, and see if that works for you, please?
- This reply was modified 2 years, 7 months ago by Jelena.