SwiftNinjaPro

Since the login recovery seems to be fixed, I’ll mark this as resolved.

Figured out the issue. When I made the recovery page, I made the plugin allow the recovery url, but forgot to allow it with query’s, which the next steps set, to determine which step your on.

If you update to 1.9.1 or later it should work now. I tested the full recovery process on another ip on my own site.

For compatibility with DIGITS (OTP SMS login), try enabling the “Allow quick bots” option. If that plugin is using wp-login, that should avoid killing the page, so that plugin can do its thing. If it’s already enabled, I made a small change (in v1.9.2 or later), so that option also allows it without query’s, incase its using post method instead.

If that doesn’t work, a new option you can try, enable “If not wp-admin url, Hide message and attempt login redirect” option, just in case the plugin is confused by a 404 response.

hope this helps.

• This reply was modified 4 years, 7 months ago by SwiftNinjaPro.
• This reply was modified 4 years, 7 months ago by SwiftNinjaPro.

Just released an update, and added a recovery page.

To reactivate the plugin (while its deactivated):
1. log into your site as administrator
2. activate the plugin
3. on your site, go to: /wp-admin/admin.php?page=swiftninjapro-wp-login-whitelist-ip-recovery
4. follow the directions on that page
After that, the plugins “Enabled” setting will be disabled, and the plugin will not run, but settings still accessible.

I guess you could try this:

– create a page with a URL you will allow the user to see.

– check if the page is accessed from localhost.

– only redirect localhost to the iframe src.

– set the page URL to the src of the iframe.

now, even if the user clicks on the URL, they still won’t see the other URL the iframe redirected to. Note: the IP detection and redirect have to be done server side (php) so the URL will not be sent to the client if they access the page directly.

If you need to write php on a wordpress page, I found a plugin for that here: https://www.ads-software.com/plugins/php-everywhere/

• This reply was modified 4 years, 10 months ago by SwiftNinjaPro.

I see the issue is the iframe. Because an iframe is open on a seperate origin, the plugin cannot control what happens there. Unless the website that iframe opens, specifically prevents that key, I have no way of blocking that, because it is a seperate origin, and the browser will not allow that control for the users security. unfortunately there is no way to control what goes on in an iframe. as soon as a user clicks off the page origin, all scripts connected to blocking a keypress are disabled, and the iframe now controls the keypresses, since an iframe is basically another website. sorry for the inconvenience.

After doing some tests with the plugin, I can’t seem to recreate the problem. controle + u is already blocked. Check to see if you have the latest version of the plugin.

solved fro google cloud. had to set to fine-grained access control

Fixed it in version 5.0

I have noticed that. It seems Microsoft edge pauses JavaScript when console is open. Since console is client side, the scripts to detect it have to be client side. The block can’t work 100% of the time, and users can disable JavaScript in there browser. The plugin can make it harder for hackers, but not impossible. I will try to think of a way to fix it, but not sure if anything will work.

edit: I think I have one idea that might work.

• This reply was modified 5 years, 7 months ago by Jan Dembowski.
• This reply was modified 5 years, 7 months ago by SwiftNinjaPro. Reason: Idea