pronl

@bosreclame

Is there any indication the database backups are failing ?

Like not receiving the backup email or no backup files being created in the
wp-content/uploads/ithemes-security/backups folder ?
(Do note absence of any of these could also be explained by the backup settings you are currently using).

Anyway also check the server error_log for any relevant errors.

@sagarsarkar

When you started this topic you mentioned:

… accessing .htaccess

Now it’s suddenly:

… any edit at nginx.conf file wont reflect.

?

Anyway I’m sure these issues can easily be resolved.
Contact Pantheon and ask for their help.
Or buy an iThemes Security Pro license and get support from iThemes.

As of now unsubscribed from this topic ??

@sagarsarkar

There is no such thing as plugin compatibility with a named hosting company.
That is if “Pantheon” is a hosting company. Never heard of them.
Anyway perhaps you should contact Pantheon.

@markclifford

(Missed your last post so this is just a reminder that my message below is a response to your earlier post).

Ok, I see.
Temporarily deactivating the iTSec plugin automatically clears any plugin rules added to the .htaccess file … No need to remove those lines manually ??

Hmm, looks like your IP is getting banned in the .htaccess file.
(Which means you cannot access any file … not just the wp-login.php file.)

Which is weird, because your IP is automatically whitelisted (temporarily for 24 hours) by the plugin when logging in as a user with the Administrator role. Or have you not at least logged in once as a user with the Administrator role assigned ?

Please provide the following info which will give me some context:

WordPress 4.8.1 ?
iTSec plugin 6.4.0 ?
Apache version ?
PHP version ?
Local dev env ?
Linux/Windows ?
Multi Site env ?

If it is indeed the plugin banning your IP you could permanently whitelist your IP in the plugin Global Settings module while you are still developing the login page.

• This reply was modified 7 years, 7 months ago by pronl. Reason: Added a short clarification of my post

@markclifford

Temporarily deactivate the iTSec plugin.

If the issue persists it’s not an iTSec plugin issue.

@sagarsarkar

There is only one version of this plugin which should run fine on most envs.

Probably best to look into the errors.

Providing some screenshots would probably be helpful.

@magicfilou

Try and add this code to your active theme functions.php file:

add_filter( 'authenticate', 'one_session_per_user', 30, 3 );

function one_session_per_user( $user, $username, $password ) {
	if ( is_wp_error( $user ) ) {
		return $user;
	}

	$sessions = WP_Session_Tokens::get_instance( $user->ID );
	$all_sessions = $sessions->get_all();
	if ( count( $all_sessions ) ) {
		$user = new WP_Error( 'already_signed_in', __( '<strong>ERROR</strong>: User already logged in.' ) );
	}

	return $user;
}

Tested, and seems to work but use it at your own risk.

@magicfilou

No, the free plugin does not include that option.

iThemes Security Pro also does not include the option you described but it does include a module named User Security Check that will allow you to see sessions of who’s logged in — and be able to log them out instantly, everywhere. Not exactly what you are looking for but it does give you some session control.

For more info about the User Security Check module read the article below:

New WordPress User Security Check Helps You Review, Take Action on User Security

@tazotodua

Hmmm, I just tested the regex search pattern being used in an online regular expressions tool. Just to see what it takes to narrow down the matches …
The regex search pattern is: (\$table_prefix\s*=\s*)([‘”]).+?\2(\s*;)

Turns out this pattern works fine (PCRE) as it is.
It only seems to match $table_prefix declarations …
So $myvar = ‘bla’; does not match.

Based on this result I cannot explain your ‘bug’.
Seems like the regex search pattern is working differently in your env.

@tazotodua

I’m not sure wp-config.php is the right place for adding custom code.
I feel like it’s a risk.

I’ve read the Editing wp-config.php article in the Codex but there is no info about custom code in the wp-config.php file … so I think it should be avoided.

WordPress configuration is mostly done by defining constants in the wp-config.php file. There is no mention whatsoever of custom PHP code. Yes, it’s technically possible but that does not mean you should do it …

Have you ever considered relocating the custom PHP code to another place ?
Like in a plugin or the active theme functions.php file.

Anyway the iTSec plugin Change Database Table Prefix feature is using a regex search/replace method which is used by many others … I don’t think they are ALL doing it wrong ??
That said, the regex search pattern could be tweaked to narrow down the matches…

For anyone else reading this topic, what do you think ?

@tazotodua

Can you provide some context as to why those variables exist in the first place ?

Normally there is only 1 variable defined in the wp-config.php file: $table_prefix

I guess the Change Database Prefix feature expects only 1 variable to be defined.

@bunneahmunkeah

According to the 6.3.0 ChangeLog:

Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.

@painfreecrafts

The log out appears to be pointing to the unchanged login, and not the renamed hidden login – which is a problem, obviously!

I guess you are referring to a URL like this:

https://www.painefreecrafts.nl/wp-login.php?itsec-hb-token=wplogin&action=logout&_wpnonce=2bb4328507

The plugin is not supposed to change the logout URL above into https://www.painefreecrafts.nl/wplogin?action=logout&etc…

So the logout URL being used is perfectly fine because it contains the extra URL parameter to make it work: itsec-hb-token=wplogin.

Sounds like this is not an iTSec plugin issue.
What happens when you temporarily deactivate the iTSec plugin ?

• This reply was modified 7 years, 7 months ago by pronl. Reason: Corrections

@adespont

The error translated in English is:

error: TypeError: Unable to get property “top” of undefined or null reference.

@soportee

Ok, so this is probably what you are doing (Guessing because your problem description is not very clear):

Let’s assume the Hide Backend slug is set to: letmein

1. Access https://www.example.com/letmein
Result: Redirect to https://www.example.com/wp-login.php?itsec-hb-token=letmein
Dashboard login screen displays ok.

2. Access https://www.example.com/wp-login.php?itsec-hb-token=trumpisanidiot
Result: No redirect.
Dashboard login screen displays ok.

Step 2 works because at step 1 a itsec-hb-login-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cookie was created in your browser which allows the regular (wp-login.php but also wp-admin url) to function for an hour. Only AFTER the cookie expires (> 1 hour), ANY wp-login.php url will no longer work (from the same browser).

So after cookie expiration you have to use https://www.example.com/letmein (or https://www.example.com/wp-login.php?itsec-hb-token=letmein) again.