jenssegers / optimus

🤖 Id obfuscation based on Knuth's multiplicative hashing method for PHP.
https://jenssegers.com
MIT License
1.27k stars 74 forks source link

Symfony-Flex recipe #40

Open ckrack opened 6 years ago

ckrack commented 6 years ago

Hi!

I like to use Optimus as an easy way to obfuscate Ids. I don't like to configure it every time.

It would be great to have a Symfony-Flex recipe that would provide an autowireable service with pre-configured random values. A ParamConverter could also be provided by the recipe.

jenssegers commented 4 years ago

Would be nice if someone could add some symfony documentation in the readme. I'm really familiar with flex recipes.

ckrack commented 4 years ago

Hi Jens, I have this on my todo list. Will add a flex recipe and update the docs with a link.

ckrack commented 4 years ago

Hi @jenssegers, I've extracted my paramconverter and twig extension into ckrack/optimus-bundle. A flex-recipe is underway as a PR to recipes-contrib.

There might be some changes to the recipe. Actually, to enable the service for the main optimus class, we need to have working parameters for it in place. Otherwise the installation of the bundle will fail due to the exception thrown during Optimus instantiation. I chose to use the lowest prime possible (3) and to describe the setup in readme and post-install.txt. If you prefer, we could change this to use the values from the examples in the readme of this repo, but they actually mismatch (i tried using them in the tests).

There is no such thing as a post-install-hook for recipes in Symfony, so adding good spark numbers must be done by hand. There's one way to accomplish something similar, but i'm not sure this should be used. Flex recipes can add scripts to auto-scripts that are run after every composer update/install. I could add a command that replaces the default values in the env or config by values generated by Energon. Replacing them means that this will only be applied once and will only replace the weak defaults. The script will always run, though. This should probably be discussed in the PR of the recipe though.

For Symfony 5 compatibility, It'd be great if you can tag a new release containing the Command return fix.