Aspnetcore.docs: Cookie Policy Middleware in 2.X

Created on 22 Jun 2018  ยท  20Comments  ยท  Source: dotnet/AspNetCore.Docs

I'm little confused on Configuration here... there's a section about what to do in ConfigureServices() then a section about what to do in Configure(). Should I be performing both for a 2.1 app?

Also, when I tried using app.UseCookieAuthentication() in Configure() I got:

UseCookieAuthentication is obsolete. Configure Cookie authentication with AddAuthentication().AddCookie in ConfigureServices. See https://go.microsoft.com/fwlink/?linkid=845470 for more details.


Document Details

โš  Do not edit this section. It is required for docs.microsoft.com โžŸ GitHub issue linking.

P4 Source - Docs.ms

Most helpful comment

giphy 1

All 20 comments

Should I be performing both for a 2.1 app?

Yes

when I tried using app.UseCookieAuthentication() in Configure() I got ...

It's a 1.x app? If so, that's fine. They didn't version their API comments for that notice; so even if used in a 1.x app or looking at the API in the API browser online set to 1.0/1.1, it will always say that the method is obsolete.

I'd like to do something in the topic to surface this.

Should I be performing both for a 2.1 app?

Yes

Interesting. I got it working w/o including it.

It's a 1.x app?

Nope, 2.1. WebApiCookieAuth.csproj.

<TargetFramework>netcoreapp2.1</TargetFramework>

Hold a sec ... sorry ... too many balls in the air this morning. ๐Ÿ˜…

UseCookieAuthentication is a 1.x or netfx (Katana) concept. It only appears in the topic for 1.x tabs. For 2.x, it would be services.AddAuthentication and app.UseAuthentication.

I was confused for a sec because our netfx sample does use UseCookieAuthentication with Katana auth middleware, and we've had that question before ... 'you say use it ... you're using it ... why does it show up obsolete?' I'll need to do some work in the topic to clarify on that point (but perhaps more so in the cookie sharing topic than this one; here it's something that the 1.x tab should remark on).

I must be confused on your OP. You say you aren't using both the instructions for ConfigureServices and Configure, but the sample app you point to does use both AddAuthentication and UseAuthentication. What's your first question again? Which instructions do you mean?

We're good on the other point, correct? app.UseCookieAuthentication would be for a 1.x app. You have it correct in your sample app with app.UseAuthentication.

It only appears in the topic for 1.x tabs

That's right, my bad. I must have thought I was on the 2.X tab and wasn't. I see that now after re-reviewing.

Thanks for your super fast responses!! ๐Ÿ™

No prob. Let's leave this open. I'd like to do something about the "this is obsolete API" situation. I think you're the third person to ask here ... and that's just on the docs repo. I suspect it's been asked elsewhere, too. I'll confer with @HaoK to see if we can address it in the topic. Thanks for mentioning it.

Copy that.

Sidenote: I hope you guys adopt the Versioning Support in MSFT Docs

Example:
image

@spottedmahn We do have the version selector in the ASP.NET Core docs now. We're slowly working on eliminating the tabs within the docs. You'll notice that the Table of Contents changes based on the selected version. For example, the SignalR node only appears when ASP.NET Core 2.1 is selected.

giphy 1

I'm happy to give it a shot and convert some over. Where can I learn more about the new approach?

I'll let @scottaddie advise but just mention to search for open assigned issues on a topic prior to working it. For example, updates from tabs to moniker-ranges are active for the sample updates, which are being tracked by #5495.

@spottedmahn Unfortunately, there's no public info available about the new versioning approach. I'm sure that's soon to change. In the meantime, see https://github.com/aspnet/Docs/blob/master/aspnetcore/web-api/action-return-types.md for an example. You'll notice the following syntax:

::: moniker range=">= aspnetcore-2.1"

This content displays for ASP.NET Core 2.1 and above.

::: moniker-end

::: moniker range="<= aspnetcore-2.0"

This content displays for ASP.NET Core 2.0 and below.

::: moniker-end

There are variations of this scattered all throughout the docs. The goal is to replace the ASP.NET 1.x/2.x tabs with what you see above.

I thought we agreed that every moniker-range start and end would get the one line space treatment and the most recent version goes first (like we did with tabs; although I understand the tab ordering reasoning was the main need to do so), so let me know if that's incorrect. I would've (have been really) setting up that example like this on my topic updates recently ...

blah blah blah ... all versions content here

::: moniker range=">= aspnetcore-2.1"

This content displays for ASP.NET Core 2.1 and above.

::: moniker-end

::: moniker range="<= aspnetcore-2.0"

This content displays for ASP.NET Core 2.0 and below.

::: moniker-end

yackety yack yack McYack ... all versions content here

@guardrex I've updated my response. You are correct.

Made all the changes on Startup.cs, and the Account Folder, yet my pages still don't redirect when I visit the Authorized pages, yet I have put "option.Conventions.AuthorizePage("/Home/About");"
On say the About page. Anyone know why?

@daugmaud The sample app is a known-working example. Compare your app to that and see what difference(s) might be causing the problem ...

https://github.com/aspnet/Docs/tree/master/aspnetcore/security/authentication/cookie/samples/2.x/CookieSample

Thanks @guardrex for your quick response, been trying to compare, kindly let me know if there is any other file other than startup.cs and the accounts folder that need to be altered. Regards

"/Home/About"

Is this MVC or Razor Pages. AuthorizePage will only work with Razor Pages pages. For MVC, decorate a controller or action with [Authorize]. See: https://docs.microsoft.com/aspnet/core/security/authorization/simple

Thank you so much, [Authorize] that guide was useful. It worked

I don't think we'll need to spend cycles dealing with the 'obsolete API' warnings in API topics given that we'll be dropping coverage between now and after the 1.x EOL (June/2019). ๐Ÿƒ๐Ÿƒ๐Ÿƒ๐Ÿ˜…

Was this page helpful?
0 / 5 - 0 ratings