-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[FrameworkBundle] Allow secrets vaults to be used directly outside Symfony #47445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@nicolas-grekas as previously discussed. This should be everything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a line in the changelog file of the bundle please?
Done. Hopefully the changelog entry is fine this way? |
@nicolas-grekas Do I need to change anything else because the bot added the "needs work" tag? |
Thank you @AndreasA. |
Sorry to comment on a closed ticket but I have to say that I'm personally not very satisfied with the path we took here:
All in all, I fail to see what prevents us from opening this API the same way we usually do it for other parts of the framework. |
I can reply for myself: I rejected #45571 because I've no idea which part of which domain those classes would cover. Creating a new component sends a message that this new lib will solve a useful problem. But I honestly don't know the boundaries of a new symfony/secrets component. Those classes look a bit "random" to me from a domain coverage pov. I preferred not opening a pandora box by creating a component that would raise false expectations - thus be deceptive. Also, I don't plan to invest my time into defining+implementing a "secrets" domain. |
Personally, I would also have preferred a component but this way there are already some possibilities:
One thing that I am not sure about is, if the commands should also remove the |
It could be interesting to contribute those back here. If we have many of them, then maybe a new component would make sense, as a generic way to plug in specific vault implementations.
if that's the plan, then we can keep the |
@nicolas-grekas regarding the custom package, that is currently not the plan - at least not by me 😄 Just mentioned it. And I think it would be easier without internal because then it is BC safe and easier to extract new versions, with internal it might break in the future 😄 but not that important. The other things though are still valid. and they do help. As mentioned in the worst case, one can now use the vaults by requiring the framework-bundle, even if they only use the vaults. Regarding additional vaults, not currenlty planned, but maybe in the future. In which case I might create a PR, once it works. |
We are also loading secrets from aws secrets manager but it is encapsulated in a service which is loaded by an See symfony/src/Symfony/Component/DependencyInjection/EnvVarLoaderInterface.php Lines 14 to 25 in 7e8fdd8
|
@faizanakram99 I know that it is possible to use env var processors to do so, I am doing something similar in another project. I just think it would be nicer to use a corresponding vault as that would also allow the Thanks for the tip anyway. |
This PR removes the internal tag from the secrets vaults.
This allows developers to use them directly without the need to use Symfony config etc. They still have to install the whole framework bundle but that just means an overhead during download, they are still able to directly instantiate the vault using
new SodiumVault(....)
for instance.Furthermore, by removing internal from the AbstractVault, it is possible to add a custom vault and specify it replacing the
secrets.vault
service for instance.See ticket: #44151
and previous PR: #45571