Aspnetcore.docs: UseRequestLocalization() call has to be placed after UseAuthentication()

[joakimriedel]

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"); }));

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d1833676-ff1b-c587-cc9c-81afffa8ef68
• Version Independent ID: ad989395-3f49-4d55-521e-cf6fe56281ee
• Content: Globalization and localization in ASP.NET Core
• Content Source: aspnetcore/fundamentals/localization.md
• Product: aspnet-core
• Technology: aspnetcore-fundamentals
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

@ryanbrandenburg please review.

[Rick-Anderson]

@jcemoller ping me if you don't get a response by end of day 9-11.

[joakimriedel]

@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.

[Rick-Anderson]

@ryanbrandenburg please review.

[joakimriedel]

@Rick-Anderson any news now for rtm?

[Rick-Anderson]

@mkArtakMSFT please assign a reviewer.
@ryanbrandenburg can you review - this looks short but important.

[ryanbrandenburg]

This issue was moved to aspnet/AspNetCore#14391

[ryanbrandenburg]

Seems like this is a technical problem/question rather than a docs question. I've moved it to aspnet/AspNetCore where we track that kind of thing.

[joakimriedel]

@ryanbrandenburg well, could be either or.

The documentation for 2.2 (and current 3.0) states that the following is the correct way to initialize request localization;

(from https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-3.0#localization-middleware)
```c#
var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("fr"),
};

app.UseRequestLocalization(new RequestLocalizationOptions
{
DefaultRequestCulture = new RequestCulture("en-US"),
// Formatting numbers, dates, etc.
SupportedCultures = supportedCultures,
// UI strings that we have localized.
SupportedUICultures = supportedCultures
});

app.UseStaticFiles();
// To configure external authentication,
// see: http://go.microsoft.com/fwlink/?LinkID=532715
app.UseAuthentication();
app.UseMvcWithDefaultRoute();
```

This works correctly in 2.2, but not in 3.0 as I wrote above since UseRequestLocalization call must be placed after UseAuthentication.

If this is due to a bug/regression in 3.0 - it seems correct to move to https://github.com/aspnet/AspNetCore.

On the other hand, if this a new requirement to properly configure localization in 3.0 - it's a documentation issue.

Who should I ping to work this out?

[Rick-Anderson]

UseRequestLocalization()call has to be placed after UseAuthentication()

See https://github.com/aspnet/AspNetCore/issues/14391

[Rick-Anderson]

@hishamco please review

[hishamco]

Sure but I like to know if it's doc or technical issue? I saw @ryanbrandenburg comment and that's why I asked the question again

[Rick-Anderson]

@jcemoller

If this is due to a bug/regression in 3.0 - it seems correct to move to https://github.com/aspnet/AspNetCore.

Is the 3.1 behavior the same?

[ryanbrandenburg]

@jcemoller I think I see the problem here, I was misunderstanding your description of the problem until this morning. Placing UseRequestLocalization after UseAuthentication is a requirement for you (not in general) because of your custom RequestCultureProvider that checks IsAuthenticated. That provider assumes that the user has already been (or failed to be) authenticated, but since the Configure method is constructing a pipeline that hasn't happened yet (unless UseAuthentication is above UseRequestLocalization) and it defaults to false.

Phrased a bit more abstractly, the Use extension calls in Configure create an ordered pipeline, so any extension A which relies on another extension B must be placed after extension B. If a developer changes those relationships by introducing a new dependency (as in this case), then they must also update that ordering.

Given that I'm going to close that out, but if you have suggestions on improvements we could make to the Docs to avoid confusion like let us know and we'll consider a revision.

[joakimriedel]

Thanks @ryanbrandenburg for the explanation. I think it broke for me when I reordered the middleware during migration to 3.0; changing the order of UseAuthenticationmade it work again.

Would there ever be a case where UseAuthenticationmust be placed after UseRequestLocalization? Otherwise I would suggest changing the default order in the documentation, or adding a Note section explaining that it must be changed in order to access the authenticated user. I think it is a common pattern to use the authenticated user's settings stored somewhere (like a database or other store) to set the display language.

[ryanbrandenburg]

@jcemoller , that sounds like a customer experience question that @danroth27 is better suited to handle.

Personally my vote would be no. I think there are so many possible (even likely/common) interactions between our various middle-wares that if we start documenting the ordering changes for all of them it would crowd the documentation. I DO think we could do a better job of helping people understand the middle-ware system in general and how it might affect their scenarios so they can reason about it for their unique app, but I'm not sure what specific changes that would entail.

[joakimriedel]

@ryanbrandenburg I understand this from a maintenance perspective. However, the middleware order is already documented in a certain way in the mentioned page with "_The localization middleware must be configured before any middleware which might check the request culture_" together with a code section that made me think that UseAuthenticationalso had to be afterwards in the Startup.cs file. Took me some time to debug, but I learned the importance of middleware ordering the hard way.

Don't know about any specific changes but a generic note section that would say something like "depending on what you need to access in your handler - ensure the middleware is ordered correctly by following the instructions on some_other_page" would have at least given me the pointers to resolve this quicker on my own.