Forum Replies Created

Viewing 15 replies - 526 through 540 (of 2,197 total)
  • @css31

    No, I’ve tried to find out in the past (you are not the first person hitting this issue). It’s a mystery where the extra wp-login slug comes from.

    Is this a manual WP download/install or was WP installed as an App from your hosting provider cPanel env ? Perhaps you should talk with your hosting provider.

    dwinden

    @css1

    wp-login is not an official WP Dashboard login slug.

    Enabling the iTSec plugin Hide Backend feature will disable all 5 standard WP Dashboard login slugs like:

    • wp-admin
    • admin
    • login
    • dashboard
    • wp-login.php

    Track down where the extra wp-login slug comes from and disable it there.

    dwinden

    @falk Wussow

    Reproduces easily. Also in my case on the third 404 the following 14 warnings are displayed on the frontend page (as well as reported in the web server error_log):

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 977

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 978

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 979

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 980

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 981

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 982

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 985

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 986

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 987

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 988

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 991

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 992

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 993

    Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 994
    error

    This is while using the Twenty Sixteen theme. You might not see the warnings as the frontend page goes black and\or WP_DEBUG is set to false …

    dwinden

    @backups

    Ok, in that case I think it was just a side effect of an issue introduced in the previous release (5.3.1).
    Probably nothing to worry about unless these notices are persistent.

    Do verify on the iTSec plugin Dashboard page, in the System Information metabox, all the way at the bottom, that the current Build Version is 4040. No upgrade code will be executed once you are on the latest Build Version.

    Also verify there is an index.php file in both of these folders:

    wp-content/uploads/ithemes-security/backups
    wp-content/uploads/ithemes-security/logs

    dwinden

    @backups

    The indicated lines are upgrade lines.
    It seems the log_location setting did not exist in the itsec_global option as stored in the wp_options table while upgrading.

    Any idea from what version you updated ? Anything recent or an old release ?
    You can find a version history on this page.

    dwinden

    @russ

    Thank you for this valuable contribution to the community.

    It think you should know that the premium iTSec Pro plugin is the free iTSec plugin + 10 extra features.
    So if the free plugin is ‘a way to crash your site’, the paid for iTSec Pro plugin will crash it as well … but I think you get my point, it’s nonsens.
    Sure it’s always possible to crash a site using this plugin. Every env is unique and a bug may roar its ugly head at any time. Note the plugin even warns you:

    Warning

    Please read the installation instructions and FAQ before installing this plugin. iThemes Security makes significant changes to your database and other site files which can be problematic, so a backup is strongly recommended before making any changes to your site with this plugin. While problems are rare, most support requests involve the failure to make a proper backup before installation.

    I understand your frustration but would a plugin that has been worked on non stop for 5 years really be that bad ?
    Is this forum swamped with similar topics from other users experiencing the same issue ?

    Should we even attempt to help you or should we consider this topic as an attempt to let off some steam ?

    Anyway a minor issue was introduced with the 5.3.1 release, but there are no similar symptoms reported as observed in your topic.
    Which doesn’t mean that there are no ugly bugs out there yet to be discovered …

    iThemes has acknowledged the minor issue and is working hard to release an update asap.

    dwinden

    @gerroald

    No problem. I do feel I need to make one correction.

    iTSec 5.3.1 (without my fix) does create .htaccess files in all three (ithemes-security, backups and logs) folders.

    I guess the 3 fopen/fwrite/fclose groups of commands that create the .htaccess file(s) should be removed from the activate_execute() function in the class-itsec-setup.php file…

    dwinden

    @WebEndev

    I made a quick and dirty fix to illustrate what is wrong and to demonstrate how to fix it. However this code needs some more work.

    The original piece of code never worked. The fix makes it work but also revealed a new bug …
    For instance with my fix applied there is no .htaccess file created in the logs folder…

    I’m sure in the near future iThemes will release an update that will include a more comprehensive fix.

    One other thing to consider is the content of the .htaccess file.
    ‘Deny from all’ is Apache 2.2.x syntax only.
    Would make sense to add Apache 2.4.x syntax as well.
    ‘Require all denied’

    Another thing is why is the ITSEC_Logger class so worried about the logs subfolder ? It should only worry about it when the Log Type setting is set to File Only or Both
    Most people use the default, Database Only
    So who cares whether the logs subfolder exists or not ?

    dwinden

    @falk Wussow & @WebEndev & @gerroald

    The reason why this warning is happening is because the @mkdir() command positioned 2 lines earlier is also failing…
    Unfortunately because of the @ we have never been notified of this.

    The @mkdir() command is failing because it tries to create a …/ithemes-security/logs subfolder while the parent ithemes-security folder does not yet exist.

    Change your code to look like this and the issue will be fixed:

    //Make sure the ithemes-security directory and logs subdirectory are created
    if ( ! is_dir( $itsec_globals['ithemes_log_dir'] ) ) {
    	@mkdir( $itsec_globals['ithemes_dir'] );  // <- Add this new line
    	@mkdir( $itsec_globals['ithemes_log_dir'] );
    	// Make sure we have an index file to block directory listing
    	file_put_contents( path_join( $itsec_globals['ithemes_log_dir'], 'index.php' ), "<?php\n// Silence is golden." );
    }

    dwinden

    @viscodesign

    Was iThemes able to assist you in solving your issue ?
    If so please take a moment to share the solution with the community.

    dwinden

    @falk Wussow & @WebEndev

    Is there also not a .htaccess file in the logs (and backups) folder(s) ?

    Note all (3) commands for the .htaccess file creation are already preceeded by a @.
    So if a .htaccess file does not exist in these folders its creation is also failing but you are not getting any warning because the fopen\fwrite\fclose commands are all already preceeded by a @.

    dwinden

    @jfheath

    Where normal = IPv4 ?

    For every ip address listed in the Ban Users setting the following lines are normally added to the .htaccess file:

    # Ban Hosts - Security > Settings > Banned Users
    SetEnvIF REMOTE_ADDR "^196\.163\.172\.21$" DenyAccess
    SetEnvIF X-FORWARDED-FOR "^196\.163\.172\.21$" DenyAccess
    SetEnvIF X-CLUSTER-CLIENT-IP "^196\.163\.172\.21$" DenyAccess
    <IfModule mod_authz_core.c>
    	<RequireAll>
    		Require all granted
    		Require not env DenyAccess
    		Require not ip 196.163.172.21
    	</RequireAll>
    </IfModule>
    <IfModule !mod_authz_core.c>
    	Order allow,deny
    	Allow from all
    	Deny from env=DenyAccess
    	Deny from 196.163.172.21
    </IfModule>

    The above example is an IPv4 address example which I expect to work just fine. However it seems there is an issue with IPv6 support in combination with Apache 2.2.x
    IPv6 support was added to the plugin in the latest 5.3.0 release. So if your issue started after updating from 5.2.1 to 5.3.0 there is a good chance the IPv6 support is causing you trouble.

    Unfortunately there is not much info in the other topic as iThemes decided to switch to email communication while investigating this issue …

    dwinden

    @jfheath

    It would be interesting to know what Apache web server version you are using.

    Do you remember whether you had IP addresses listed as banned in IPv4 and\or IPv6 format ?

    IPv4 = xxx.xxx.xxx.xxx(/xx)
    IPv6 = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx(/xxx)

    Anything between () is optional.

    If your issue is solely caused by the IP addresses listed in the Ban Hosts setting you can prevent any IP address being added automatically to this setting by disabling the Blacklist Repeat Offender setting in the Global Settings section.
    This would also allow you to enable the Write to Files setting again without a chance of the issue reoccurring.

    There seems to be another topic where iThemes is investigating this issue.

    dwinden

    @obertscloud

    If the File Change Detection setting is enabled try and disable it.

    dwinden

    @obertscloud

    Please post the content of your .htaccess file while having this problem.
    And also let us know what Apache web server version you are using.

    dwinden

Viewing 15 replies - 526 through 540 (of 2,197 total)