BulletProof Security
[resolved] Autolock not working (32 posts)

  1. WayneM1
    Posted 2 years ago #

    Updating my site from .47.8 to .47.9

    I always have all my file/folder permissions set as recommend by BPS. I believe these settings are consistent with what my host allows, as they work just fine.

    When I do the update, all the permissions remain intact - except for the ../.htaccess which goes from the recommended 404 to 644.

    I can easily re-lock it to 404 using the handy lock feature in the BPS admin panel.

    I do have the autolock set to "ON".

    I can post or email you my system info details if that helps. I'm on a standard HostGator shared server that is generally setup to be very friendly for this sort of thing.

    Although I'm only now reporting this, I'm pretty sure this has been the case for me for at least the last two version updates (possibly more).

    Thanks once again for this awesome plugin :-)


  2. AITpro
    Plugin Author

    Posted 2 years ago #

    In code processing you will see that last displayed message for the last code function that was processed. Is it possible that you are looking at the last message for the last code function that was processed? Your actual current status can be checked by either Refreshing your Browser or clicking the BPS Menu link.

    When automatic .htaccess file updating occurs on BPS upgrades the root .htaccess is automatically unlocked to 644 permssions so that BPS can write any new .htaccess code or make any new changes to the root .htaccess file. The automatic update will NOT change any custom .htaccess code that you personally added to your root .htaccess file and will ONLY change the standard BPS .htaccess code that needs to be modified or add new additional .htaccess code.

    If you have AutoLock turned On then your root .htaccess file is automatically locked again with 404 file permissions. It is of course possible that some particular situation, scenario, difference or restriction on your particular web host or Server will prevent AutoLock from working correctly.

  3. WayneM1
    Posted 2 years ago #

    Thanks for the response... tastes a little bit like it was "canned" (when did you start doing that?)

    I'll pick choice #3 since this has nothing to do with cached messages, and the update has no problem with changing the permissions as needed.

    The problem is that with the autolock feature set to "ON", the .htaccess file permissions get changed from 404 to 644. The permissions are not autolocked back to the 404. This is easy to confirm by looking at the current security status in the admin panel (after reloading the page). It's also clear that the permissions are not reset to 404 by looking at the permissions via file manager or FTP client.

    Conclusion: Autolock is not working correctly.

    Question: Is there a fix?

    Here's my server info:

    ==Website / Server / Opcode Cache / Accelerators / IP Info==
    Website Root Folder: http://mywebsite.com
    Document Root Path: /home/mywebsite/public_html/sites/mywebsite
    WP ABSPATH: /home/mywebsite/public_html/sites/mywebsite/
    Parent Directory: /home/mywebsite/public_html/sites
    Server / Website IP Address: xxx.xxx.xxx.xxx
    Host by Address: xxx.xxx.xxx.xxx
    DNS Name Server: xxx.xxx.xxx.xxx
    Public IP / Your Computer IP Address: xxx.xxx.xxx.xxx
    Server Type: Apache
    Operating System: Linux
    Server API: cgi-fcgi - Your Host Server is using CGI.
    cURL: cURL Extension is Loaded
    Zend Engine Version: 2.2.0
    Zend Guard/Optimizer: Zend Optimizer Extension is Loaded
    ionCube Loader: ionCube Loader Extension is Loaded Version: 40202
    Suhosin: Suhosin is Not Installed/Loaded
    APC: APC Extension is Not Loaded
    eAccelerator: eAccelerator Extension is Not Loaded
    XCache: XCache Extension is Not Loaded
    Varnish: Varnish Extension is Not Loaded
    Memcache: Memcache Extension is Not Loaded
    Memcached: Memcached Extension is Not Loaded
    ==PHP Server / PHP.ini Info== 	  	
    PHP Version: 5.2.17
    PHP Memory Usage: 34.61 MB
    WordPress Admin Memory Limit: 256M
    WordPress Base Memory Limit: 40M
    PHP Actual Configuration Memory Limit: 64M
    PHP Max Upload Size: 64M
    PHP Max Post Size: 64M
    PHP Safe Mode: Off
    PHP Allow URL fopen: Off
    PHP Allow URL Include: Off
    PHP Display Errors: Off
    PHP Display Startup Errors: Off
    PHP Expose PHP: On
    PHP Register Globals: On
    PHP MySQL Allow Persistent Connections: Off
    PHP Output Buffering:
    PHP Max Script Execution Time: 30 Seconds
    PHP Magic Quotes GPC: Off
    PHP open_basedir: not in use
    PHP XML Support: Yes
    PHP IPTC Support: Yes
    PHP Exif Support: Yes
    ==SQL Database / Permalink Structure / WP Installation Folder==
    MySQL Database Version: 5.5.23-55
    MySQL Client Version: 5.5.23
    Database Host: localhost
    Database Name: mywebsite_mywebsite
    Database User: mywebsite_mywebsite
    SQL Mode: Not Set
    WordPress Installation Folder: /
    WordPress Installation Type: Root Folder Installation
    Network/Multisite: Multisite is Not enabled
    WP Permalink Structure: /%year%/%monthnum%/%day%/%postname%/
    Permalinks Enabled: ? Permalinks are Enabled
    PHP Version Check: ? Using PHP5
    Browser Compression Supported: gzip, deflate

    Thanks :-)

  4. AITpro
    Plugin Author

    Posted 2 years ago #

    Not sure what you mean with "canned"?

    Messages would not be cached. What happens with coding is this. You create a function and when the function is processed/executed then the text message that you have added within the function is displayed in that particular Browser window at that moment when the Browser is Refreshed.

    So what can happen is something like this.

    The automatic file updating starts by processing/executing the function that does that. When the function completes you see the message that goes with the function, but where you actually are in the code processing/execution is you have already moved on to the next function that is now doing whatever it is designed to do. The Browser is still where it was and displays the last function that was processed/executed. If I were to force Browser Refreshes then you would see your actual status in real-time. Since this is frowned upon in general then forcing Browser Refreshes is not something that I will probably ever do. I may do something with the PHP sleep() function though in the future to trick the eye into seeing/believing real-time status display.

    AutoLock works perfectly fine on the BPS testing sites:

    Standard single WordPress installation testing site.
    - root and subdirectory testing sites
    Network/Multisite WordPress installation testing site.
    - subdirectory and subdomain
    GWIOD WordPress installation testing sites.
    - standard WordPress installation testing site
    - Network/MU WordPress installation testing site
    Various subdomain and subdirectory combinations of the sites listed above.

    Let me rephrase my statement. Your web host or Server configuration for your particular Host may cause AutoLock not to be working correctly for any one of various possible reasons. From the feedback that I get the AutoLock feature appears to work fine on 1,000's of different web hosts with millions of different possible configuration scenarios/possibilities, but of course there are going to be some configuration scenarios where I assume AutoLock would not work.

    So in summary, I am not sure why AutoLock is not working on your particular website/Server/Configuation. On all the BPS testing site types it works fine. The general feedback that I get is AutoLock works fine so this leaves the only possible conclusion.

    Something about your particular website/Server is causing AutoLock not to work. It is also possible that another plugin could be preventing AutoLock from locking the file I guess. So the next logical troubleshooting steps would be to figure out what on your particular website is causing AutoLock not to work.

    Your Server info although very helpful in eliminating several different possible reasons for AutoLock not working on your particular website does not display what is causing the problem on your particular website.

    Try this test.

    Edit your root .htaccess file and change the version number in your root .htaccess file with the BPS built-in .htaccess file editor. Then Refresh you Browser. What should happen is that your Root .htaccess file should be unlocked and the version number will be changed. Next click on the BPS Menu link. The displayed messages from the last function that was processed will go away and the next function that locks the root .htaccess file should now show that status of the next function that has been processed.

    Let me know if the root .htaccess file is locked again after doing these testing steps.

  5. AITpro
    Plugin Author

    Posted 2 years ago #

    Did you try the test? Oh and I forgot to mention that when you change the version number just change it back one version for testing. Change .47.9 to .47.8. Let me know if the root .htaccess file is locked again after doing these testing steps.

  6. AITpro
    Plugin Author

    Posted 2 years ago #

    Did you try the test?

  7. WayneM1
    Posted 2 years ago #

    I did all the steps you indicated.

    I was able to edit the current .htaccess file to change the version number. Of course, I had to unlock the file using the unlock feature. That worked fine.

    I did the refresh and so on, and never saw any error message about the version number (re: "If you edit the BULLETPROOF .47.9 >>>>>>> SECURE .HTACCESS text above you will see error messages on the BPS Security Status page").

    The .htaccess file did not autolock.

    I did this on two sites: one with version .47.8 the other version .47.9.

    I can make you an admin at one of my sites if you want to give it a try. Just let me know where to email you the login credentials.

  8. AITpro
    Plugin Author

    Posted 2 years ago #

    We cannot offer to login to folks sites because we do not have the time or resources to offer that kind of service.

    Ok so we know for sure that AutoLock does NOT work on your website for some odd reason. AutoLock does work in general so it is not an issue with the BPS AutoLock coding itself. So the next logical thing to look at would be plugins or maybe some Server configuration issue or maybe some setting in your web host control panel.

    let's start with plugins. Please post a list of all the plugins you use.

  9. AITpro
    Plugin Author

    Posted 2 years ago #

    I do have a HostGator testing Hosting account so I will test and see what happens. I noticed that you have posted this same issue a few times in the past so let me check and see if there is some kind of issue with HostGator itself. I seriously doubt that, but will eliminate that possibility.

  10. AITpro
    Plugin Author

    Posted 2 years ago #

    Ok i just tested upgrading from .47.8 to .47.9 on HostGator and AutoLock works fine. It is not your web host so either you have setup something in cPanel that is blocking AutoLock or one of your plugins is doing this or you have done some sort of custom configuration/custom coding on your particular website that is causing AutoLock not to work.

  11. AITpro
    Plugin Author

    Posted 2 years ago #

    Also by default HostGator accounts have WP Super Cache already installed and configured so it might be possible that this has something to do with it. On my HostGator testing account WP Super Cache is activated and is in use.

  12. AITpro
    Plugin Author

    Posted 2 years ago #

    Are you using cPanel HotLink Protection? If so, this wreaks all kinds of havoc not only with BPS, but also with WordPress itself.

  13. AITpro
    Plugin Author

    Posted 2 years ago #

    Did you give up on figuring out what is causing this on your website? Thanks.

  14. AITpro
    Plugin Author

    Posted 2 years ago #

    Resolving. If you want to work on this at a later time then unresolve this Thread and post your lastest status. What you have tested or not tested, etc.

  15. WayneM1
    Posted 2 years ago #

    I have a recently installed WP site in which I deactivated all the plugins except BPS. Reverted to the previous BPS version. Set it up, set the permissions, did the upgrade no problem - But, the autolock did not work.

    I do not have hotlink protection on (never have).

    I do not use automatic installations of WP from webhost cPanels. I do it myself. I do not use any caching.

    What sort of settings would I be looking for that might be the problem. Something in a custom PHP.INI? Custom directive/setting an the root .htaccess? I may have done some tweaking settings in those files as if recommended for better server security. Maybe something is too restrictive? So, what would I be looking for?

  16. AITpro
    Plugin Author

    Posted 2 years ago #

    The cPanel HotLink Protection is always on - you cannot turn it off - the Enable/Disable options are also broken, but if your root .htaccess file is locked then it will prevent the tool from automatically wiping out your root .htaccess code.

    I don't think the HotLink Protection Tool is the problem in your case. Actually I am completely out of ideas. Since the automatic unlocking of the file is working from 404 to 644 then nothing on your website is blocking the CHMOD function itself so it should also work the same to CHMOD back from 644 to 404 to lock the file again.

    The only idea I have left for you to check would be to check your php error log file or your Server log file for the problem that is occurring on your site. But the error is probably only going to tell you that the code is failing for some reason on your site and not what is actually causing that code to fail.

  17. AITpro
    Plugin Author

    Posted 2 years ago #

    Hmm ok I thought of another possibility.

    These web hosts are automatically excluded from locking the file.

    $ExcludedHosts = array('webmasters.com', 'rzone.de', 'softcomca.com');

    If the php dns_get_record() function is being blocked then maybe that might cause the issue, but I very seriously doubt that would be the problem.

    The BPS autolock code check:

    if (@$permsHtaccess == '644.' && !in_array(bps_DNS_NS(), $ExcludedHosts) && $options['bps_root_htaccess_autolock'] != 'Off') {
    		if (substr($sapi_type, 0, 3) == 'cgi' || substr($sapi_type, 0, 9) == 'litespeed' || substr($sapi_type, 0, 7) == 'caudium' || substr($sapi_type, 0, 8) == 'webjames' || substr($sapi_type, 0, 3) == 'tux' || substr($sapi_type, 0, 5) == 'roxen' || substr($sapi_type, 0, 6) == 'thttpd' || substr($sapi_type, 0, 6) == 'phttpd' || substr($sapi_type, 0, 10) == 'continuity' || substr($sapi_type, 0, 6) == 'pi3web' || substr($sapi_type, 0, 6) == 'milter') {
    		chmod($filename, 0404);

    What you could do to eliminate that first part of the check is not working on your site for some reason is to comment out the first set of "if" checks and comment out the last brace as shown below. Then test and see what happens. This code is in the /bulletproof-security/includes/functions.php file at code line 330.

    //if (@$permsHtaccess == '644.' && !in_array(bps_DNS_NS(), $ExcludedHosts) && $options['bps_root_htaccess_autolock'] != 'Off') {
    		if (substr($sapi_type, 0, 3) == 'cgi' || substr($sapi_type, 0, 9) == 'litespeed' || substr($sapi_type, 0, 7) == 'caudium' || substr($sapi_type, 0, 8) == 'webjames' || substr($sapi_type, 0, 3) == 'tux' || substr($sapi_type, 0, 5) == 'roxen' || substr($sapi_type, 0, 6) == 'thttpd' || substr($sapi_type, 0, 6) == 'phttpd' || substr($sapi_type, 0, 10) == 'continuity' || substr($sapi_type, 0, 6) == 'pi3web' || substr($sapi_type, 0, 6) == 'milter') {
    		chmod($filename, 0404);
  18. WayneM1
    Posted 2 years ago #

    I commented out the first part of the check as you suggested. Ran a few tests. The file unlocks to write, but still does not autolock.

    There's nothing in any php error logs.

    Thanks for trying.

  19. AITpro
    Plugin Author

    Posted 2 years ago #

    wow crazy stuff. I guess this will just have to remain an unsolved mystery. Sorry.

  20. WayneM1
    Posted 2 years ago #

    I suppose the thing that has been lurking in my mind the whole time with this issue is this:

    If I can lock the .htaccess file using the "Lock .htaccess File" button in the BPS admin panel, why can't the Autolock feature do the same thing? Clearly, it's working with the same server configuration and WP installation. Doesn't that seem odd to you? What are these features doing that are the same/different?

    I need something that can "auto-click" that file lock button...

  21. AITpro
    Plugin Author

    Posted 2 years ago #

    Yep logically the autolock code should be working on your site. Try using the WordPress Debug code in your wp-config.php file to see if it finds out what on your website is preventing the autolock code from working normally.

    The WordPress debug log is created here - /wp-content/debug.log. Post any errors you see related to the autolock code.

    * For developers: WordPress debugging mode.
    * Change this to true to enable the display of notices during development.
    * It is strongly recommended that plugin and theme developers use WP_DEBUG
    * in their development environments.
    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', true);
  22. WayneM1
    Posted 2 years ago #

    Did that. Ran some tests. No debug.log file created - so I guess, no errors. Also no errors were shown in the server error log file during this testing.

    Oh well.

  23. AITpro
    Plugin Author

    Posted 2 years ago #

    Well actually that is a clue in itself that the CHMOD function is not being blocked/failing in any way and also that the autolock code itself is not being blocked/failing.

    So that means the code is being processed/executed, but is not fully completing successfully for some reason on your site.

    This could be because you have some custom .htaccess code that is breaking the sequence of root .htaccess code checks and then when it gets to the CHMOD function it does not actually even fire because of that custom .htaccess code. This is a hypothetical logical guess.

    Do these steps.
    1. Make a backup of your .htaccess files using BulletProof Security built-in Backup.
    2. Click the AutoMagic buttons - If you have custom .htaccess code that you added to BPS Custom Code then make a copy of it and delete it BEFORE you click the AutoMagic buttons. You can add it back later after testing.
    3. Activate All BulletProof Modes.
    4. Change the version number at the top of the root .htaccess file from .48 to .47.9 using ONLY the BPS htaccess file editor (do not do this manually via FTP) to force the autoupdate function to fire.
    5. Click on the WordPress Dashboard link/panel or any other WordPress link/panel like the Plugins panel/link - DO NOT Refresh your Browser.
    6. Go to the BPS Edit/Upload/Download page and check if your root .htaccess file was locked.

    Let me know what happens.

  24. AITpro
    Plugin Author

    Posted 2 years ago #

    I updated the steps. Please check them again. Thanks.

  25. WayneM1
    Posted 2 years ago #

    (didn't we do this test about 6 days ago, or one very similar?)

    I followed your step by step instructions above.

    The version number change on the root .htaccess was successful.
    The file did not autolock.

    More info: Yesterday I temporarily removed my server's root .htaccess file (at the root of all my server files at public_html). I did this to see if there were any settings there that might be problematic, and to disable my custom tweaked global php.ini. It made no difference.

  26. AITpro
    Plugin Author

    Posted 2 years ago #

    hmm what exactly is your site architecture? The autolock function only checks the .htaccess file for the site where BPS is installed, but it is possible that you have some sort of site architecture or maybe DNS or maybe some other unusual setup that is causing this problem.

    Where is your website installed exactly and what exactly is in the .htaccess file in the /public_html folder?

    my website is installed in this subfolder - /myWordPressSite
    the .htaccess file in the website root folder / public_html is a standard WordPress .htaccess file or is a BPS secure .htaccess file without any modifications / with modifications, etc.

    Do you have a GWIOD site? - Giving WordPress Its Own Directory

  27. WayneM1
    Posted 2 years ago #

    It's nothing unusual. It's standard HostGator Baby Croc. I've got a few dozen addon domains that I keep in separate folders in a sub folder off of public_html. The root .htaccess file in public_html effects the server settings in the subfolders. Things like allowing indexes or denys, etc. Each addon domain has it's own installation of WP with all the files like .htaccess that go with it. No funny DNS stuff.

    My root .htaccess is here:

    Each WP site is in it's own domain/folder:
    serverroot/public_html/addeddomains/domain1/ (wordpress index.php is here)
    serverroot/public_html/addeddomains/domain2/ (wordpress index.php is here)

  28. AITpro
    Plugin Author

    Posted 2 years ago #

    So are all of your websites under this Hosting account having the same problem with autolock?

    If so, that tells you that the problem is with something that controls/is configured/is a setting applied to all of your sites and not an issue that is occuring on each individual site, unless of course you have some plugin installed on all of these sites that is causing this problem.

    The only other thing that i can think of is this. HostGator has some automated script setup to do some sort of check for WP Super Cache .htaccess code. On my HostGator testing site I have left WP Super Cache installed and configured on that site.

    So here is a logical hypothetical scenario that could be what is happening. Since you are not using WP Super Cache then maybe the HostGator check to see if the WP Super Cache .htaccess code exists is interrupting/interfering with the autolock check or is unlocking the file again after it has been locked.

    What i have noticed is that if i remove the WP Super Cache .htaccess code then HostGator automatically adds it back into the root .htaccess file. What this means is that HostGator is unlocking the file automatically so that it can check and add that WP Super Cache .htaccess code if it does not exist. Logically then what could be happening is that autolock does lock the file, but HostGator unlocks it again to do the check for the WP Super Cache .htaccess code.

    There is a checkbox setting somewhere, which i cannot remember where exactly since i did this so long ago that is specifically for WP Super Cache. So maybe you need to change or uncheck this checkbox?

  29. AITpro
    Plugin Author

    Posted 2 years ago #

    And this is just an FYI for BlueHost/HostMonster/FastDomain folks. If you have a domain that is suspended due to forgetting about paying the yearly domain renewal then this Host will automatically unlock the root .htaccess file and add several lines of .htaccess code in the root .htaccess file. The .htaccess code serves as a reminder and I don't remember exactly what that code does, but it gives folks some sort of heads up notification to remind them about the domain renewal that needs attention.

  30. WayneM1
    Posted 2 years ago #

    I'll keep looking to see if I can dig up any server settings or configuration that might be causing this issue.

    In the mean time, let's revisit this part of the mystery...

    My earlier question: "If I can lock the .htaccess file using the "Lock .htaccess File" button in the BPS admin panel, why can't the Autolock feature do the same thing? Clearly, it's working with the same server configuration and WP installation. Doesn't that seem odd to you? What are these features doing that are the same/different?"

    It's not like my server configuration won't allow the chmod of the file. If I click that button - it locks the file. So, why can't the autolock do it's check and use the same routine to lock it? Does it do the locking differently in those two functions? To me, this is the most baffling part :-(

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic