Save password parameter default values to user secrets#4507
Save password parameter default values to user secrets#4507DamianEdwards merged 17 commits intomainfrom
Conversation
|
This feels like an opportunity to design a better API for parameter defaults. |
|
What did you have in mind? |
There was a problem hiding this comment.
This file is no longer needed as it previously contained the hacked workaround for the lack of this feature.
| if (!TrySetUserSecret(applicationName, configurationKey, value)) | ||
| { | ||
| throw new DistributedApplicationException($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); | ||
| Debug.WriteLine($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); |
There was a problem hiding this comment.
To make it a bit easier to see if it's doesn't succeed during dev. There's no logging at this stage and swallowing blindly just seems bad mmm'k
There was a problem hiding this comment.
Would it be possible for us to get the ability to log here? (obviously not in this PR) It seems like a big hole that we aren't able to log things until the app is built. Especially as we add more functionality earlier in the app. Our only options are throw or eat...
There was a problem hiding this comment.
Another cause for this to not succeed is if appHostAssembly is null. Do we need to support that scenario? It feels odd that we would Debug.WriteLine if someone passed null (which we claim to support). We basically wouldn't do anything.
There was a problem hiding this comment.
Logged #4597 to track enabling logging pre-host build.
There was a problem hiding this comment.
Another cause for this to not succeed is if appHostAssembly is null. Do we need to support that scenario?
@eerhardt I made it non-nullable and don't call in now if the appHostAssembly is null for some reason.
There was a problem hiding this comment.
Now that it's internal, it is less of a concern. But this sounds good.
|
Couple of things playing around with this locally.
PEBCAK |
Are you talking about supporting binding to KeyVault etc? |
|
@DamianEdwards I'm pretty happy with this. I made a minor change so that the secrets file is formatted when we save it. I'm not sure I like the |
|
@eerhardt can you review please |
| if (!TrySetUserSecret(applicationName, configurationKey, value)) | ||
| { | ||
| throw new DistributedApplicationException($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); | ||
| Debug.WriteLine($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); |
There was a problem hiding this comment.
Would it be possible for us to get the ability to log here? (obviously not in this PR) It seems like a big hole that we aren't able to log things until the app is built. Especially as we add more functionality earlier in the app. Our only options are throw or eat...
| if (!TrySetUserSecret(applicationName, configurationKey, value)) | ||
| { | ||
| throw new DistributedApplicationException($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); | ||
| Debug.WriteLine($"Failed to set value for parameter '{parameterName}' in application '{applicationName}' to user secrets."); |
There was a problem hiding this comment.
Another cause for this to not succeed is if appHostAssembly is null. Do we need to support that scenario? It feels odd that we would Debug.WriteLine if someone passed null (which we claim to support). We basically wouldn't do anything.
eerhardt
left a comment
There was a problem hiding this comment.
LGTM.
Nice work! This is going to solve a lot of problems with container persistence.
| /// <summary> | ||
| /// The assembly of the app host. | ||
| /// </summary> | ||
| Assembly? AppHostAssembly { get; } |
There was a problem hiding this comment.
Is this new public API?
| public string AppHostDirectory { get; } | ||
|
|
||
| /// <inheritdoc /> | ||
| public Assembly? AppHostAssembly => _options.Assembly; |
There was a problem hiding this comment.
Do we really need to expose this as public API?
There was a problem hiding this comment.
We can revert but it's kinda useful to have. I think originally it was required when the user secrets stuff was public and each resource extension method was doing the logic to add the user secrets parameter default, but it could all be internal now.
Adds
UserSecretsParameterDefaultwhich wraps aParameterDefaultand saves the value returned by itsGetDefaultValuemethod to the AppHost user secrets.Updated all resources that use
GeneratedParameterDefaultto generate a default password/apikey to wrap it inUserSecretsParameterDefaultso that the default value is saved to user secrets.Fixes #1151
Microsoft Reviewers: Open in CodeFlow