No announcement yet.

File caching and security settings not working

  • Filter
  • Time
  • Show
Clear All
new posts

  • File caching and security settings not working

    I tried to setup file caching datastore as per -

    Set file permissions to 777 on this -

    Cache path is outside the doc-root as under in config.php -
    $config['Cache']['fileCachePath'] = '/home/user_name/files/cache';

    (www resides in - '/home/user_name/site_name')

    Uncommented the line in config.php -
    $config['Datastore']['class'] = 'vB_Datastore_Filecache';

    Refreshed the homepage. It seemed to have created a replica php file (datastore_cache.php) in the cache path directory (with 644 permission) but no data is written in the file. I changed the permission to 777, refreshed the homepage but still no data is written to it. It has the same validation logic on the top and maybe that is the reason it is not writing cache data? I commented the line and refreshed the homepage but still no data is written to the file

    if(!defined('VB_ENTRY')) die('Access denied.');

    2. Also, does this cache file get refreshed with a cache lifetime (at least once a day or on each change to settings/options, etc)? For instance, does it get refreshed after an update with any new version data? The config file says, "You may need to clear this cache after installing/upgrading. You can do this either in the control panel (Maintenance) or by restarting the web server." This could be automated in the update scripts and also whenever we change options/settings/etc to empty the folder so it gets rebuilt - just in case we forget it.

    3. After eliminating modcp and admincp folders from the doc-root in v5.5.6, is this setting still relevant?

    $config['Misc']['modcpdir'] = 'modcp';

    I tried changing this value and renaming the core/modcp folder for security reasons.but it gave an invalid page error on clicking MOD in the footer menu.

    4. I did not see a corresponding admincpdir config setting to rename the folder for security reasons.

    Please help...

    Last edited by webcms; Tue 17th Mar '20, 8:03am.

  • #2
    1. This is the directory where vBulletin will try to write your files: '/home/user_name/files/cache'; Not in /core/includes/datastore. The first directory has to be writable by your web server user.

    2. It should get rebuilt when you update the datastore. This is changing settings, permissions, attachment type value, and phrases among other things.

    3. You cannot change the name of the modcp directory in vBulletin 5. This value should remain the default. The only reason it is still there is because the ModCP is considered deprecated and we have only fixed the most egregious bugs with it. Hopefully it will be completely removed in the future.

    The idea of changing the directory is based on security by obfuscation. This has proven ineffective in study after study. The "feature" was useful during 15 years ago during the vBulletin 3 days because 90% of customers didn't have access to better security practices. Later users would use .htaccess to protect these directories. Today, we have Two-Factor Authorization and IP Blocking built into the software. If you want to secure the AdminCP and ModCP directories in current versions of vBulletin, you should enable and use Two/Multi-Factor Authentication that is built into the software. I only recommend using IP Blocking if you can guarantee that you'll always have the same IP Address when accessing the site. You can enable both of these in the /core/includes/config.php file.

    4. As stated, renaming these directories is outdated and ineffective as far as security goes.

    If you want to secure your site in 2020, this is what you need to do...
    1. Install an SSL Certificate on your server.
    2. Enable 2FA in the /core/includes/config.php file.
    3. Configure 2FA in your User Settings within vBulletin.
    4. Download vBulletin using its PHAR configuration accessed by customizing your download package in the Member's Area.
    5. Make sure the vBulletin files are not writable by the web server (all of the files in your default upload directory).
    6. Store Attachments outside of the web root directory (usually public_html).
    7. Use MemcacheD for your datastore cache.
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API - Full / Mobile
    Vote for your favorite feature requests and the bugs you want to see fixed.


    • #3
      The directory and the file are writable and it did write the PHP and index.html files inside the folder. When I clear system cache, the file is getting updated timestamp. Also, when I rename the file and refresh the homepage, it is re-creating a new file as expected. However, its contents are just this basic skeleton whereas I was expecting serialized data written inside it - which means it is still hitting dB for data with no caching -

      <? php if(!defined('VB_ENTRY')) die('Access denied.');
      ### start options ###
      $options = '';
      ### end options ###
      ### start bitfields ###
      $bitfields = '';
      ### end bitfields ###
      ### start usergroupcache ###
      $usergroupcache = '';
      ### end usergroupcache ###
      ### start stylecache ###
      $stylecache = '';
      ### end stylecache ###
      ### start languagecache ###
      $languagecache = '';
      ### end languagecache ###
      ### start products ###
      $products = '';
      ### end products ###
      ### start hooks ###
      $hooks = '';
      ### end hooks ###
      At this point, it seems something in vB is not working right.

      Last edited by webcms; Tue 17th Mar '20, 3:05pm.


      • #4
        I just changed one Options setting and noticed that it wrote all the options settings only as an array inside the cache file.

        I changed a language phrase and refreshed the homepage but it did not populate any language data inside the cache file.

        Also, other sections such as usergroup, style, etc are still empty as above and not expected behavior. When we change the cache directory and when it creates the above file in the new location, it should also populate it with cache data which it did not. Additionally, it is populating cache data only when I change an option setting for that Option setting section only - leaving other sections empty (maybe until they are edited in admin panel) - which means data in these empty sections is still fetched from the dB for each page load without using any cache.

        If I rename or delete the cache file, it is re-creating just the empty file again. This would be an issue when I update the site with next version of vB at which time I need to empty the cache folder as per the documentation and it would only create an empty cache file until some changes are made to the settings, etc in admin panel. Ideally, the update script should be automated to empty the cache folder. Empty System Cache or a page load should re-create the missing cache file (it does) and also populate it with all cache data inside it without needing any edits in admin panel (does not). In other words, anytime time a cache file is re-created or a missing cache file is created, it should also be populated with all cache data. Also anytime there is a cache-miss, it should create and populate the cache file.

        If I use MemCacheD, I wouldn't even know if it is storing any cache data or not and expect the behavior would be the same as above except for storage medium.

        Please let me know your thoughts.
        Last edited by webcms; Tue 17th Mar '20, 3:37pm.


        • #5
          Run /core/install/upgrade.php to rebuild everything in the filecache. This will rebuild the cache. Otherwise, editing a language builds that part. Editing a style builds that part. Etc... There is no reason to rebuild these caches unless the static information changes.

          The Filecache is pretty archaic and we do not recommend using it. It doesn't provide either security or performance benefits in 99% of all cases. In fact from a security perspective, it should be considered completely insecure. You're putting every single option, setting, permission, security keys, etc... into a plain text file that anyone who gains access to the server can see.

          What is being cached is pretty static information and already cached in the datastore table within the database. Database queries are generally more performant than reading and scanning arrays within files. So when a miss is encountered, it just grabs if from that table. Writing out this file for a miss in general usage for any end user would be a significant performance decrease in your site. Falling back to the database probably adds less than 20 milliseconds to the page generation time. Especially since MySQL has its own caching for queries. Common queries are often pre-compiled and stored in memory. If for some reason the database table does not have the information, the system will query the original table for the information and rebuild itself as designed. This would happen on every page load if necessary (though something would be horribly wrong at this point) and the end user will never even notice.

          In the long run we really want to remove the filecache from the system completely because there are better solutions out there for caching. That is where development has been put in the last few years. Even when using the filecache classes in vBulletin, the database cache will be used more often. The only thing that is cached is some of the contents of the datastore table.

          As far as seeing data in Memcached, then you can do this with its command line commands or one of any number of web based scripts available. Generally speaking you don't want this information accessible to the web though.
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud demonstration site.
          vBulletin 5 API - Full / Mobile
          Vote for your favorite feature requests and the bugs you want to see fixed.


          Related Topics