Replies: 3 comments 1 reply
-
Unfortunately, these repro steps are not sufficient to demonstrate that there is a bug in the framework and not in the app. If you can provide a minimal repro that demonstrates just this issue and a specific trigger for the |
Beta Was this translation helpful? Give feedback.
-
I suspected that this would be the response, which is why I almost didn't submit this. I can't repro it, I can only show you that it happens. The auth code has always been complex, which is why I also didn't look at the source, because I wouldn't know where to start. From what I described, you could logically concluded that a minimal repo wouldn't be useful. That repo would be the code samples in the docs, which would then have to run for some amount of time in an Azure Linux App Service before it broke. That I can't do this does not mean that there's no problem. My assumption is that the place where the registration of handlers is stored is actually volatile after startup. So why is that? |
Beta Was this translation helpful? Give feedback.
-
I'm not sure why we decided to make it possible to mutate authentication schemes after app start. That decision to allow for that much flexibility was before my time, but my guess is that it was support very dynamic multitenant auth scenarios that might be desired by framework or CMS authors. I haven't seen it used outside of our tests and samples like this one though. Assuming that the issue really is the authentication scheme being removed after application start, and not the application restarting without registering any schemes, you should be able to see it by registering a custom builder.Services.AddSingleton<IAuthenticationSchemeProvider, LoggingAuthSchemeProvider>();
// ...
public class LoggingAuthSchemeProvider(IOptions<AuthenticationOptions> options, ILogger<LoggingAuthSchemeProvider> logger)
: AuthenticationSchemeProvider(options)
{
public override bool TryAddScheme(AuthenticationScheme scheme)
{
logger.LogInformation("Adding scheme '{SchemeName}'.", scheme.Name);
return base.TryAddScheme(scheme);
}
public override void RemoveScheme(string name)
{
logger.LogCritical("Removing scheme '{SchemeName}'!!!{StackTrace}", name, Environment.StackTrace);
base.RemoveScheme(name);
}
} |
Beta Was this translation helpful? Give feedback.
-
Is there an existing issue for this?
Describe the bug
The CI build of POP Forums seems to have an issue where over time, the registered auth handler becomes "deregistered" until I cycle the Azure App Service. I can't reproduce this in other instances I have running, but it happens frequently on this one. Everything runs as expected, until it doesn't.
The Program of the app calls an extension method which registers the auth:
Another extension method registers middleware...
And here's the middleware. The exception is thrown on the
context.AuthenticateAsync
call:Exception:
This code has been mostly unchanged going back to .NET v5. Again, when the app starts, everything is fine, but when I come back to it after a few days, it's returning 500's with the above exception and stack trace. I can't think of any reason that after the app is started, the auth scheme would no longer be in place.
Expected Behavior
The auth scheme is durably registered.
Steps To Reproduce
Exceptions (if any)
.NET Version
8.0
Anything else?
No response
Beta Was this translation helpful? Give feedback.
All reactions