_From @jcemoller on Monday, September 9, 2019 1:54:37 PM_
I've tried to migrate a net core 2.2 web application to net core 3.0 preview 9. I'm having troubles with middleware, where HttpContext.User.Identity.IsAuthenticated always returns false even if the user is authenticated. To ensure that I do not made any mistakes during migration of our application, I even tried to set up a new 3.0 web application project and follow the instructions on this page. In the code below IsAuthenticated is always false.
How do I make this work in 3.0? I have to check authenticated user to resolve the culture based on a SQL query.
c#
options.RequestCultureProviders.Insert(0, new CustomRequestCultureProvider(async context =>
{
var isAuthenticated = context.User.Identity.IsAuthenticated; // always false in 3.0 preview9
// My custom request culture logic
return new ProviderCultureResult("en");
}));
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
_Copied from original issue: aspnet/AspNetCore.Docs#14221_
_From @Rick-Anderson on Monday, September 9, 2019 5:21:43 PM_
@ryanbrandenburg please review.
_From @Rick-Anderson on Monday, September 9, 2019 5:24:18 PM_
@jcemoller ping me if you don't get a response by end of day 9-11.
_From @jcemoller on Wednesday, September 11, 2019 3:35:09 PM_
@Rick-Anderson spent the last two days trying to find any resolution to this, and I think I found one. It seems that in 3.0, the UseRequestLocalization() call has to be placed after UseAuthentication() call in Configure(). Previously, in 2.2 and also as noted in the documentation under https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-3.0#implement-a-strategy-to-select-the-languageculture-for-each-request, the recommendation was to place UseRequestLocalization() before UseStaticFiles() and UseAuthentication().
I have yet to find any side-effects by moving the call later in setup, but if this is the new policy it should be reflected in the docs for 3.0. Thanks.
_From @Rick-Anderson on Wednesday, September 11, 2019 4:49:14 PM_
@ryanbrandenburg please review.
_From @jcemoller on Tuesday, September 24, 2019 9:26:15 AM_
@Rick-Anderson any news now for rtm?
_From @Rick-Anderson on Tuesday, September 24, 2019 4:44:14 PM_
@mkArtakMSFT please assign a reviewer.
@ryanbrandenburg can you review - this looks short but important.
Thanks for contacting us, @jcemoller.
@HaoK can you please look into this? Thanks.
//cc @blowdart
Have there been any changes in behavior with respect to when RequestCultureProvider does its evaluation? We didn't make any changes to how UseAuthentication works in 3.0,
options.RequestCultureProviders.Insert(0, new CustomRequestCultureProvider(async context =>
{
var isAuthenticated = context.User.Identity.IsAuthenticated; // always false in 3.0 preview9
// My custom request culture logic
return new ProviderCultureResult("en");
}));
context.User will only be set after UseAuthentication has run, so without knowing anything about how request localization works, for this to have worked in 2.2, the culture provider code above must have run after UseAuthentication exected in 2.2, it looks like in 3.0 that's no longer the case, which is why moving the authentication middleware after continues to work.
@mkArtakMSFT this behavior change looks like its most likely coming from RequestLocalization/and or how its being used (earlier now?) Perhaps related to endpoint routing changes? But I think its unlikely at this point to be anything in Auth. It looks like the RequestCultureProviders is being created at a different (earlier) point now
Ping @mkArtakMSFT
Is the localization middleware before or after authentication? Middleware order matters.
Bumping this @mkArtakMSFT
Who can answer the question by @rynowak
Is the localization middleware before or after authentication? Middleware order matters.
Bumping this again @mkArtakMSFT. We've been live with the workaround for some time and do not notice any side effects, but would be nice to know if it's a bug or docs issue - for the latter would be great if the docs were updated to reflect the change in 3.0 compared to 2.2.
@hishamco please review.
context.User will only be set after UseAuthentication has run, so without knowing anything about how request localization works
If you looked to the Localization.StarterWeb in the entropy repo UseAuthentication() called after UseRequestLocalization()
@jcemoller do you have a repo that reproduce the issue, so I can have a look
Bumping this again @mkArtakMSFT. We've been live with the workaround for some time and do not notice any side effects, but would be nice to know if it's a bug or docs issue - for the latter would be great if the docs were updated to reflect the change in 3.0 compared to 2.2.
@jcemoller what is the specific workaround you're referring to here?
@hishamco @mkArtakMSFT
I've now created a new project from a 2.2 template, see commit https://github.com/jcemoller/net-core-localization-bug/commit/b40367a30fb82d398f6803590b9b678e1c32548b.
In the repo code, if UseRequestLocalization is placed in LOCATION 1 you will always see the text "IsAuthenticated is FALSE" in Home/Index. If UseRequestLocalization is placed in LOCATION 2, after logging in the text will change to "IsAuthenticated is TRUE".
I'm sure that the order could be reversed in my project before migrating to 3.0, but I cannot reproduce this with a clean repo from 2.2 template. It must be some other code in the actual project where I experienced the issue that made it working even though the order was reversed there.
Still, it would be great if the docs at https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2#localization-middleware were updated to reflect that in order to use IsAuthenticated, you cannot put it in the advised location but it has to be after UseAuthentication.
Thanks.
Thanks @jcemoller
@Rick-Anderson can you update the docs if you have a time, or I will reschedule this
@hishamco whoever gets to it first
See https://github.com/aspnet/AspNetCore.Docs/issues/14221
Most helpful comment
@hishamco @mkArtakMSFT
I've now created a new project from a 2.2 template, see commit https://github.com/jcemoller/net-core-localization-bug/commit/b40367a30fb82d398f6803590b9b678e1c32548b.
In the repo code, if
UseRequestLocalizationis placed in LOCATION 1 you will always see the text "IsAuthenticated is FALSE" in Home/Index. IfUseRequestLocalizationis placed in LOCATION 2, after logging in the text will change to "IsAuthenticated is TRUE".I'm sure that the order could be reversed in my project before migrating to 3.0, but I cannot reproduce this with a clean repo from 2.2 template. It must be some other code in the actual project where I experienced the issue that made it working even though the order was reversed there.
Still, it would be great if the docs at https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2#localization-middleware were updated to reflect that in order to use IsAuthenticated, you cannot put it in the advised location but it has to be after
UseAuthentication.Thanks.