engram-design
commented
1 month ago We use the FORMIE_SECURITY_KEY to help with encrypted fields (it's a field setting for most fields).
It's something you should add to your .env file yourself if you are using encrypted fields. It should be used separately to CRAFT_SECURITY_KEY as it's for a different purpose.
The reason for the extra one is that if you change your CRAFT_SECURITY_KEY to something else, then your encrypted field data will be inaccessible. This is common to cycle this (even automatically) when Craft itself has a security vulnerability, which is exactly what's happened in the past. Craft has cycled the CRAFT_SECURITY_KEY and has meant that submission data for encrypted fields was gone.
So yep, probably a good idea to add it to your boilerplate if you use encrypted fields. It'll fall back on CRAFT_SECURITY_KEY if you don't, but you're going to lose data if you change that down the track.
joelzerner
Question
In v2.0.39 the Formie Security Key env variable was added: Added FORMIE_SECURITY_KEY .env variable (based off CRAFT_SECURITY_KEY or SECURITY_KEY for maintaining a separate key for encrypting field values.
Just wanting to know a few details on how this works. I've noticed this appear in the .env file in some projects but then when I attempted to set a field to be encrypted in another project the variable didn't show up in .env automatically. Should this be something we add into our default .env file in our boilerplate (with Formie installed)?
If we wanted it to, could we just allow it to use the same as the SECURITY_KEY variable so we don't need to have two? Or would this be problematic?
Additional context
No response