Unable to turn Error Logging On – root .htaccess file not writable, does not exist, permissions

Home Forums BulletProof Security Free Unable to turn Error Logging On – root .htaccess file not writable, does not exist, permissions

Tagged: 

This topic contains 12 replies, has 2 voices, and was last updated by  AITpro Admin 5 years, 2 months ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #3673

    Doug B.
    Participant

    Updated my BPS to .48.1 and seem to have a couple of minor issues with the security logging function.

    I noticed that the error document declarations in my secure.htaccess file didn’t update with BPS updating – only the version number seemed to update. I activated Root Folder BulletProof Mode and then I had to remark out the 404 page declaration because I don’t want those logged. Then activated the updated htaccess. No issues there.

    I next went to the security log tab and turned it on and I got this error message:

    Error: Unable to turn Error Logging On. Either the root .htaccess file is not writable, it does not exist or the ErrorDocument .htaccess code does not exist in your Root .htaccess file. Check that the root .htaccess file exists, the code exists and that file permissions allow writing.

    Here is what is in my htaccess file:

    # BPS ERROR LOGGING AND TRACKING
    # BPS has premade 403 Forbidden, 400 Bad Request and 404 Not Found files that are used
    # to track and log 403, 400 and 404 errors that occur on your website. When a hacker attempts to
    # hack your website the hackers IP address, Host name, Request Method, Referering link, the file name or
    # requested resource, the user agent of the hacker and the query string used in the hack attempt are logged.
    # All BPS log files are htaccess protected so that only you can view them.
    # The 400.php, 403.php and 404.php files are located in /wp-content/plugins/bulletproof-security/
    # The 400 and 403 Error logging files are already set up and will automatically start logging errors
    # after you install BPS and have activated BulletProof Mode for your Root folder.
    # If you would like to log 404 errors you will need to copy the logging code in the BPS 404.php file
    # to your Theme's 404.php template file. Simple instructions are included in the BPS 404.php file.
    # You can open the BPS 404.php file using the WP Plugins Editor.
    # NOTE: By default WordPress automatically looks in your Theme's folder for a 404.php template file.
    
    ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
    ErrorDocument 401 default
    ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
    #ErrorDocument 404 /404.php

    Maybe I’m not understanding the new way of doing the logging but I tried to work with it even though you uncommented out the declarations in this version.

    Any info to get it to work or to better understand this will be appreciated

    #3682

    AITpro Admin
    Keymaster

    This previous Forum Topic you posted is stating a similar issue/problem with Error Logging not turning On / Off:  http://forum.ait-pro.com/forums/topic/error-logging-dont-turn-off-when-using-the-button/.  Is this the same issue/problem?

    Hmm I am not sure if a coding check was created for this particular scenario:  If Error logging was previously turned Off before upgrading BPS then check for that coding pattern instead of the expected coding pattern.  Will double check on that.

    Error: Unable to turn Error Logging On. Either the root .htaccess file is not writable, it does not exist or the ErrorDocument .htaccess code does not exist in your Root .htaccess file. Check that the root .htaccess file exists, the code exists and that file permissions allow writing.

    If you are seeing the message above then BPS is not able to successfully write to this file for whatever particular reason that is on your website/Server:  file permissions are set too restrictively, file or folder Ownership issue, possible open_basedir misconfiguration – just having open_basedir installed is a Server misconfiguration/mistake in my professional opinion – open_basedir does not add any security protection or value to website security whatsoever – completely useless and only causes problems for website owners.  Very similar to safe_mode which never really worked and is deprecated.

    Another possibility could be that you are not using a WordPress Custom Permalink Structure or are using a permalink hack or maybe invalid permalink structure tags.  Please post your WordPress Custom Permalink Structure.

    So you need to find out why the root .htaccess file is not writable on your particular website/Server.

    #3703

    Doug B.
    Participant

    “This previous Forum Topic you posted is stating a similar issue/problem with Error Logging not turning On / Off:  http://forum.ait-pro.com/forums/topic/error-logging-dont-turn-off-when-using-the-button/.  Is this the same issue/problem?”

    No it isn’t the same issue. That issue was I had the code manually put into my custom 404 page and the switch didn’t affect the code put in the page.

    This issue involves the 400, 401, and 403 error tracking. I don’t want to log 404 errors at this time.

     

    I just turned off logging and got the error again, logging said it was still on, and BPS tells me my site wasn’t protected by BPS which it is – this is not a new install I just upgraded to .48.1 My htacess file is my secure.root file and is active

    When I turned off logging again both errors went away and the logging says it is off now.

    I’m assuming BPS is working fine that’s why this is a minor issue related to the logging function

    Oh and I don’t have an issue with my htaccess file being writable since I’ve had BPS running for a long time and had not issues. My permalink structure is “/%year%/%monthnum%/%postname%.html”

     

    #3705

    AITpro Admin
    Keymaster

    Oh ok.  The old 404.php template code had a mistake in it in BPS .48 that is fixed in .48.1, but if you are not using this code anymore then disregard that.

    Yep, I thought you might have a permalink hack.   I believe the old problem below will no longer occur, but with that said there are no guarantees that BPS will work correctly when you use a permalink hack.  May I ask why you are using the .html permalink hack?  I will create the same scenario on a testing site and add a permalink hack and see what it breaks or if this is directly what is causing this issue/problem.

    BulletProof Security WP Error: “no input file specified”- Permalink Problems/404 Errors – using the .html permalink hack is causing 404 Errors

    If you see a “no input file specified” error then there is something wrong with your WordPress custom permalink structure.  Another cause of 404 Errors is using the .html Permalink hack.  Using .html in your WordPress Permalink Structure is considered a hack and is not a standard WordPress Custom Permalink Structure.  Example Permalink .html Hack:  /%postname%.html.  Many years ago this supposedly increased page ranking and SEO.  If that was ever really true it is definitely not true now.  Using this permalink hack will only cause your website problems and BulletProof Security will not work with this permalink hack.  You will need to change your custom permalink to a standard WordPress custom permalink structure in order to be able to use BulletProof Security.

    #3714

    Doug B.
    Participant

    I do use the .html “hack” in my permalinks for aesthetic reasons and I don’t plan on changing it any time soon

    /%year%/%monthnum%/%postname%.html

    As I reported earlier this is not a new install. I’ve been using BPS for a long time. A couple years I think.

    About a week or so ago I removed the error tracking code from my 404 page template and when the BPS update came out I thought I might try to use the declarations you had in the update for the 400-403 error tracking.

    Again my issue is only with the error tracking change to the update in that it was telling me my htacess file was not writeable when in fact it is and BPS was activated. This is the first time I’ve ever gotten an error when updating BPS. Just wanted to let you know about my issue.

    I’m not getting any 404 errors. My page is at http://www.ihumanism.org

    I’ll just leave the error tracking off.

    I think I found the problem. I went to my permalink settings page and didn’t change anything didn’t click on save and went to another page in my WordPress admin and my active htacess file was overwritten as if I had updated my permalink structure and I got the error saying BPS wasn’t active. It is probably a WordPress issue since I think your FAQ said it is overwritten if you make a change to the link structure right?

    Here is part of my current htaccess file:

    #   BULLETPROOF .48.1 >>>>>>> SECURE .HTACCESS
    
    # If you edit the  BULLETPROOF .48.1 >>>>>>> SECURE .HTACCESS text above
    # you will see error messages on the BPS Security Status page
    # BPS is reading the version number in the htaccess file to validate checks
    # If you would like to change what is displayed above you
    # will need to edit the BPS /includes/functions.php file to match your changes
    # If you update your WordPress Permalinks the code between BEGIN WordPress and
    # END WordPress is replaced by WP htaccess code.
    # BEGIN WordPress
    
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    # END WordPress
    # This removes all of the BPS security code and replaces it with just the default WP htaccess code
    # To restore this file use BPS Restore or activate BulletProof Mode for your Root folder again.
    
    # BEGIN WordPress
    
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    # END WordPress
    
    # BLOCK HOTLINKING TO IMAGES
    # To Test that your Hotlinking protection is working visit http: //altlab.com/htaccess_tutorial.html
    #RewriteEngine On
    #RewriteCond %{HTTP_REFERER} !^https?://(www\.)?add-your-domain-here\.com [NC]
    #RewriteCond %{HTTP_REFERER} !^$
    #RewriteRule .*\.(jpeg|jpg|gif|bmp|png)$ - [F]
    
    # FORBID COMMENT SPAMMERS ACCESS TO YOUR wp-comments-post.php FILE
    # This is a better approach to blocking Comment Spammers so that you do not
    # accidentally block good traffic to your website. You can add additional
    # Comment Spammer IP addresses on a case by case basis below.
    # Searchable Database of known Comment Spammers http: //www.stopforumspam.com/
    #3732

    AITpro Admin
    Keymaster

    The WordPress Permalinks page executes the WordPress flush_rewrite_rules function when you visit/access that page.  It will clear/flush your root file .htaccess code.  If you do not want to allow this then you can lock your root .htaccess file to prevent this normal occurrence.  If you are not allowed/unable to lock your root .htaccess file then you will have to activate Root folder BulletProof Mode again.  This is standard/normal.

    I will be doing some testing today and will see if I can duplicate the problem and also double check that messaging is accurate.

    #3737

    AITpro Admin
    Keymaster

    Crap I found a mistake.  I have not finished testing yet, but I forgot to add the ErrorDocument 401 default code to the Turn Off Error Logging and Turn On Error Logging form processing code.  What happens is you end up with this below when choosing Turn Off Error Logging…

    #ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
    #ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
    #ErrorDocument 404 /404.php

    …and it should be this

    #ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
    #ErrorDocument 401 default
    #ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
    #ErrorDocument 404 /404.php

    I will be releasing a new BPS version .48.2 tomorrow.

    #3738

    AITpro Admin
    Keymaster

    And yep I was able to duplicate the exact problem and see what that problem is.  The preg_match check does not factor in if one or more of the ErrorDocument directives are already previously commented out. So I will have to add or modify this check to factor that in.

    $pattern = '/#ErrorDocument\s400(.*)ErrorDocument\s404\s(.*)\/404\.php/s';

     

    #3739

    AITpro Admin
    Keymaster

    Correction:  Actually the check does already factor that in with (.*)ErrorDocument\s404….. so it is something else.

    #3741

    AITpro Admin
    Keymaster

    Duh I see it now.  The pattern check for #ErrorDocument\s400(.*)  is assuming that ErrorDocument 400 is commented out with a pound sign.  oops.

    #3755

    Doug B.
    Participant

    It is stupid for the flush_rewrite_rules function to fire just by visiting the permalink page but it good to know that can happen. I now have the htaccess file lock setting correct so that doesn’t happen to me again. I had the autolock set but hadn’t clicked on the lock button

    The problem with the error logging declarations was exactly what I was noticing. Hopefully the update will solve the issue.

    Thanks for the help

    #3758

    AITpro Admin
    Keymaster

    I think the flush_rewrite_rules function happens on Permalinks page access to automatically fix any root .htaccess code problems, but yeah I have to agree with you that the flush should probably happen after clicking the Save Changes button.  There is probably a good reason/intended purpose for this function firing on page access and not on button click?

    Thanks for catching this mistake since it also made me notice that I forgot to add the new ErrorDocument 401 default code as well.  dumb mistake.  I am just about done with testing the new code so I should be able to release .48.2 in about 2 hours.  Thanks again for pointing out this mistake.

    #3765

    AITpro Admin
    Keymaster

    BPS .48.2 has been released to fix the boo boos.  Thanks again for catching this.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.