Summary
The line (in Startup.cs) services.AddDataProtection().UseEphemeralDataProtectionProvider(); results in a warning message getting logged when the EphemeralDataProtectionProvider is instantiated. I believe the provider should NOT log a warning if it was explicitly selected.
It appears that, when the constructor receives a logger, it will always call UsingEphemeralDataProtectionProvider():
|
logger.UsingEphemeralDataProtectionProvider(); |
And UsingEphemeralDataProtectionProvider() results in a warning:
|
_usingEphemeralDataProtectionProvider = LoggerMessage.Define( |
|
eventId: new EventId(45, "UsingEphemeralDataProtectionProvider"), |
|
logLevel: LogLevel.Warning, |
|
formatString: "Using ephemeral data protection provider. Payloads will be undecipherable upon application shutdown."); |
Motivation and goals
The intent is to encourage developers to always take warnings seriously. This warning causes logs to contain warnings that developers have no choice but to ignore.
One possible solution is to simply change this warning to an information level message. This should be ok because code that employs the ephemeral data provider as a fall back is already logging an equivalent warning.
|
// Final fallback - use an ephemeral repository since we don't know where else to go. |
|
// This can only be used for development scenarios. |
|
repository = new EphemeralXmlRepository(_loggerFactory); |
|
|
|
_logger.UsingEphemeralKeyRepository(); |
A different solution would be to change UseEphemeralDataProtectionProvider() extension method to pass in a newly created option to specify that this specific warning is NOT necessary because the provider was explicitly requested.
In scope
A stateless API backend that uses JWTs to manage authentication and has no need to persist keys between instances of the application (aside from the JWT related key which is obtained from configuration).
Risks / unknowns
How might developers misinterpret/misuse this?
The current implementation, which always logs a warning, can lead developers to search for a way to avoid the ephemeral data protection provider even when it might be a good fit for their solution.
How might implementing it restrict us from other enhancements in the future? Also list any perf/security/correctness concerns.
New code that falls back on the ephemeral provider should always log a warning similar to
|
_logger.UsingEphemeralKeyRepository(); |
because the new ephemeral provider will no longer log a warning on its own.
Summary
The line (in Startup.cs)
services.AddDataProtection().UseEphemeralDataProtectionProvider();results in a warning message getting logged when theEphemeralDataProtectionProvideris instantiated. I believe the provider should NOT log a warning if it was explicitly selected.It appears that, when the constructor receives a logger, it will always call
UsingEphemeralDataProtectionProvider():aspnetcore/src/DataProtection/DataProtection/src/EphemeralDataProtectionProvider.cs
Line 60 in 6960097
And
UsingEphemeralDataProtectionProvider()results in a warning:aspnetcore/src/DataProtection/DataProtection/src/LoggingExtensions.cs
Lines 328 to 331 in 6960097
Motivation and goals
The intent is to encourage developers to always take warnings seriously. This warning causes logs to contain warnings that developers have no choice but to ignore.
One possible solution is to simply change this warning to an information level message. This should be ok because code that employs the ephemeral data provider as a fall back is already logging an equivalent warning.
aspnetcore/src/DataProtection/DataProtection/src/KeyManagement/XmlKeyManager.cs
Lines 549 to 553 in 6960097
A different solution would be to change
UseEphemeralDataProtectionProvider()extension method to pass in a newly created option to specify that this specific warning is NOT necessary because the provider was explicitly requested.In scope
A stateless API backend that uses JWTs to manage authentication and has no need to persist keys between instances of the application (aside from the JWT related key which is obtained from configuration).
Risks / unknowns
How might developers misinterpret/misuse this?
The current implementation, which always logs a warning, can lead developers to search for a way to avoid the ephemeral data protection provider even when it might be a good fit for their solution.
How might implementing it restrict us from other enhancements in the future? Also list any perf/security/correctness concerns.
New code that falls back on the ephemeral provider should always log a warning similar to
aspnetcore/src/DataProtection/DataProtection/src/KeyManagement/XmlKeyManager.cs
Line 553 in 6960097