3

New question title: "Should the sites/default/files/config folder be stored in git with it's hash suffix?"

  • " Reason I ask this is that this might cause 2 issues:
    • May be a hindrance when comparing code bases of sites, the diff comparison program would not be able to compare the contents of the config folder directly, if the suffixes are different.
    • If the site is a open collaboration project, where the code is put on github or bitbucket publicly, then the config hash suffix which is normally secret would be visible to the public and therefore the folder can be determined but the intent was to use the hash to make the folder harder to guess for security reasons.

Original question title: "Why does the Drupal 8 config folder have a long gibberish-like name, e.g.: config_wNOLcm... etc?"

  • Answer to the question about the 'gibberish' is:

This sequence is a random hash generated during the installation of your Drupalvsite. It is used to add some protection to your configuration files. Additionally to the default restriction enforced by the .htaccess file within the subdirectories of the config directory that prevents unauthorized users from seeing the content of the directories. As a result, would be really hard for someone to guess the folder's name.

Credit: Drupal 8 Configuration Management, First published March 2015, page 29

Some general references:

https://www.drupal.org/node/2360331#how-do-i-version-my-

Improve this question

1 Answer 1

Reset to default
5
  • In the site install process, Drupal will write the configuration directory path to settings.php.
    Any other deployments of the site would then make use of the directory defined in settings.php.
  • The hash itself is not information that needs protection, but it helps make the configuration harder to find in case it were not properly protected from public access.
    If you're making your entire configuration public in a repository, it is important to check that it does not contain any compromising information (e.g. API keys).

The configuration should be protected by .htaccess (which core does by default) if it is in a publicly accessible directory, making it impossible to read and not just difficult to find.

It is possible to move the sync directory to another location.
Pantheon places it in sites/default/config, with an .htaccess file to protect it.
Alternately, setting up your repository so that Drupal is not in the root folder (as Acquia does) will allow creating a configuration directory that is outside of the document root.

/
|-- docroot
|    |-- core
|    |-- modules
|    |-- ...
|
+-- config
     +-- sync
Improve this answer
6
  • +1 on your answer for your time. So does that mean that the hash suffix is no longer required, given that .htaccess prevents access? Their idea of using a suffix for making a folder hard to guess seems a bit peculiar to me, as if this really was a good idea then they'd want to do it to every folder. From your answer it sounds like this is no longer required. And perhaps now if I revisit the now released Drupal 8 since asking this question, I may find that the hash is not used and your answer is actively being used instead.
    – therobyouknow
    Jan 18, 2016 at 10:43
  • Since the hash is random per-installation, it should make an automated attack to scan Drupal sites for unprotected configuration prohibitively expensive. It may not be likely for sites to not have the .htaccess protections in-place, but it would offer a thin layer of protection should that occur. For repository-managed code bases, I would definitely recommend placing the sync directory outside of the document root, and a hash would not be necessary.
    – gapple
    Jan 18, 2016 at 23:29
  • Thanks gapple. Why would configuration in particular be vulnerable? Why not all the other Drupal files? Related to my original question: how should config be stored in git along with the rest of the Drupal code?
    – therobyouknow
    Jan 19, 2016 at 9:52
  • Most of the configuration is not remarkable (e.g. entity and field configurations), but there are likely items within configuration that should remain private such as API keys for external services.
    – gapple
    Jan 20, 2016 at 2:02
  • Ah sure that makes sense regarding API keys, certainly I have experience of that in D7, and have put that in settings.php for D7 and it is listed in .gitignore I suppose it might make sense to group all external API keys / credentials in one place and git ignore just that file and keep the rest of the config in git source. Thoughts?
    – therobyouknow
    Jan 20, 2016 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.