techdivision / form-encryption
Neos formbuilder encryption package. GPG encryption for forms, needs gpg binary.
Installs: 343
Dependents: 1
Suggesters: 0
Security: 0
Stars: 1
Watchers: 18
Forks: 0
Open Issues: 0
Type:neos-plugin
Requires
This package is auto-updated.
Last update: 2024-11-20 18:44:59 UTC
README
This package gives you a very basic PGP encryption for the neos/form-builder package.
Installation
TechDivision.Form.Encryption is available via packagist. Add "techdivision/form-encryption" : "~1.0"
to the require section of the composer.json or run composer require techdivision/form-encryption
.
Simple Setup
This enables a basic encryption with minimum configuration. You basically just need a public key.
- Install the package using
composer require techdivision/form-encryption
.
If not yet installed, it will also install the Neos Formbuilder. - Add your own pgp PUBLIC key (not as ascii, but as binary file)
gpg --dearmor < yourPublicKey.asc > yourPublicKey.gpg
Never add your private key! - Add the path to your key as well as the email-address your key is attributed with to your Settings.yaml (do not use
resource://
links here as they wont work)
TechDivision:
Form:
Encryption:
gpg:
options:
gpgArguments:
'--keyring': '%FLOW_PATH_PACKAGES%Application/TechDivision.Form.Encryption/Resources/Public/Keys/yourPublicKey.gpg'
'--recipient': 'you@domain.com'
- Add the path to your gpg binary and the homedir attribute.
TechDivision:
Form:
Encryption:
gpg:
options:
gpgBinary: '/usr/bin/gpg'
gpgArguments:
'--homedir': '~/.gnupg'
- Add the
EncryptedEmailFinisher
to your form - either in fusion or as a NodeType.
Remove any other EmailFinisher from the form.
Advanced setup
If you are familiar with gpg and want to set it up on your own, you can easily change all the arguments you want. This is useful if you want to add your keys directly in gpg, check them against a trust db etc.
FAQs
- Why did we choose an exec command over php gnupg extension?
gpg is widely spread across many *nix distributions. Enabling a simple and straightforward usage was more important than known but limited drawbacks (key validation, signing etc.). - Why didnt we use the SwiftMailer Event Dispatcher?
We tried to, but it would have required more Classes to be overwritten. - Why didnt we use the SwiftMailer Signer Pattern?
Because signing does need private keys, which we wanted to avoid in order to have a simple usage.
Contribution
We will be happy to receive pull requests - dont hesitate!