I’m wondering how I should proceed with the SECURITY_KEY
which is now mandatory in Craft 3 (RC2). It has to be the same for one project, right? So it should be shared across developers. But is it a good idea to commit it to a Git repository? I guess not.
But then – where do I put it without losing it and still sharing it with team mates.
Due to some circumstances I lost the security key of the initial installation and added a new one. Could that lead to unwanted behavior down the road?
Enlightenment of any kind is much appreciated :)
First a bit of history:
Craft 2 has a similar concept where it would store a unique random security key in craft/storage/runtime/validation.key
. Alternatively, you could set the validationKey config setting if you wanted to provide your own key instead of use the one generated by Craft.
Craft 2 would essentially only use this for encrypting cookie data in a browser for authenticated sessions. Because everything in craft/storage/runtime
is temporary and could be deleted at any time, it is important in load-balanced environments to use the validationKey
config setting and set it to the same key for every web instance behind the load balancer.
It is possible that a plugin might go through craft()->security->encrypt()
, which takes the key into account, someone nukes the validation.key
file that lives in craft/storage/runtime
and Craft is unable to decrypt the data at that point.
Craft 3 decided that it would probably need to start encrypting data in the database at some point in the future, so it needed a more reliable way to guarantee there was a security key it could use.
So craft/storage/runtime/validation.key
was deprecated and moved to craft/storage/security.key
, the validationKey
config settings was renamed to securityKey
and Craft 3 now requires it to be set in some form or another.
Craft 3 also added another way to set it if you use the composer starter project via the .env
SECURITY_KEY environment variable, so that you can use 'securityKey' => getenv('SECURITY_KEY'),
in your craft/config/general.php
file.
Now to the questions:
It has to be the same for one project, right?
It should be, if you want to reliably encrypt and decrypt data across environments.
So it should be shared across developers.
It should be, if you want to reliably encrypt and decrypt data across developers.
But is it a good idea to commit it to a Git repository?
Definitely not a public repository. Arguable in a private one.
Due to some circumstances I lost the security key of the initial installation and added a new one. Could that lead to unwanted behavior down the road?
You wouldn't be able to decrypt any data that was encrypted with the old key.
In the case of session cookies, the worst that would happen is you'd lose your current session. In the case of encrypted database email settings, you'd have to re-save your email settings. In the case that a plugin is doing some custom encrypting and decrypting and relying on Craft's craft\services\Security
class to to it, you wouldn't be able to decrypt that data.
I am nuts about books. I read on all kinds of topics. I attempt to review each book I read for the sake of my own enrichment as well as conversation starters with others.
You never know what you will find in an attic! Usually there is a hodgepodge of things buried under dust.
Most of what is included here are notes to myself. The majority of folks will not find interest in these posts.