-
Notifications
You must be signed in to change notification settings - Fork 10.3k
IIS (out-of-proc) calls AuthenticateAsync for all requests at the start of the pipeline #7750
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
Comments
Any thoughts on this? |
@fractionalJoe did you find a work-around to this issue? it is also affecting my project. |
I did. I created a wrapper service that takes the private bool HasValidSession()
{
try
{
return _httpContext.Session.Id != null;
}
catch (Exception)
{
return false;
}
} Note that Once you have that you can use something like" public void DoSomething()
{
if (!_sessionService.HasValidSession())
{
//...in my testing this only seems to happen with preflight requests, so I fail silently. Your experience may differ so test thoroughly.
return;
}
//.... whatever you really want to do here.
} |
Awesome, I'll give it a shot. Thanks for sharing! |
Note this exception is intentional to highlight middleware ordering problems. We should address the ordering issue, not the exception. That said, this particular ordering issue is difficult. The IIS Middleware is registered ahead of any app middleware like Session, and there's not a good way to insert something ahead of it. We need to re-think this code: |
That makes sense to me conceptually. Looking at the log, |
Verified using SDK 3.0.100-preview7-012742 |
When implementing a ClaimsTransformation that attempts to access HttpContext.Session, an error "Session has not been configured for this application or request." is raised by Kestrel. This is related to #3805 and this code appears to be the culprit as it invokes authentication middleware before UseSession is called in the Startup.Configure method. I can find no way to check if Session has been been configured without a try/catch block.
To Reproduce
Expected behavior
Expected behavior is that
HttpContext.Session
should returnnull
if Session is not available. Or at least there should be aHttpContext.SessionConfigured
bool that can safely check. This ClaimsTransformation will be hit constantly and an exception being thrown, caught, and ignored is unnecessary overhead, not to mention messy..Net Info
Possible Fixes
SessionConfigured
property to DefaultHttpContext. With this, I could wrap myHttpContext.Session
calls in any Auth Handler inside of aif (HttpContext.SessionConfigured) {}
block.GetSession()
method to DefaultHttpContext.Let me know if any of these solutions sound good and I'll create a pull request.
The text was updated successfully, but these errors were encountered: