Skip to content
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

Support short-time passwords (tokens) in connection strings #299

Open
kratkyzobak opened this issue Apr 10, 2023 · 2 comments
Open

Support short-time passwords (tokens) in connection strings #299

kratkyzobak opened this issue Apr 10, 2023 · 2 comments

Comments

@kratkyzobak
Copy link

There are possibilities to connect database servers using token credentials. For example https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-azure-ad-authentication

tl;dr - there are situations where you can use short-lived token instead of long-lived password to connect to database

Problem(s):

  • Access token used as password can be really short-lived (5-60 minutes). When using lazy connections in some long-running jobs, token may be already expired when trying to connect if token obtained in service creation time instead in connection time.
  • Same as previous for reconnecting during long-running job
  • Access token shoud not be obtained before lazy connection is ready made

Potential solutions:

  • Wierd one - pass reference to password instead of password itself (for example in Azure Storage SDK) - this does not solve latest issue - token has to be released not only even connection is not made, but has to be updated every tim
  • Provider of connections - using some layer above current connection class and do lazines again (doable outside of Nette)
  • Provider of password - allow password to be not only ?string, but null|string|callable():string

I would preffer last one of course. I wanted to do it and send as PR, but I feel like to need approval that it is acceptable at all. As I looked to another frameworks, their configuration usually does not support this scenario too.

@JanTvrdik
Copy link
Contributor

Are there some problem with using the second solution, i.e. having custom connection factory?

@kratkyzobak
Copy link
Author

Problem is only in mindset. Of course I can handle solving this by connection factory and/or decorator above current Connection class, where I would re-implement connection laziness.

I belive, this kind of stuff should be somehow supported by framework as short-lived passwords will be used more and more.

But I may be alone with this opinion. This is reason, why I asked first, before trying to create PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants