Guys, you can't be serious about completely changing Identity from 2.0 to 2.1 and totally ignoring the docs. Besides, why do we now have to deal with this Razor code behind nonsense in MVC applications instead of controllers? You're totally arbitrarily mixing two different approaches and forcing us to work with this mess - all that without any proper documentation. Is there still a way to scaffold MVC like Identity code when creating a new project?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
You don't have to deal with Razor Pages if you don't want to. Identity UI is just a UI implementation of Identity. It can still be used without Identity UI at all. The documentation is lacking on how to go about doing this. There has been an issue raised for the documentation issues (#6990), and it appears the docs have been updated in the repo, and are just waiting for the next publish.
While I'm a fan of Razor Pages, I'm not a fan of how Identity UI uses Areas by default. I'm not a big fan of areas because I find it counter-intuitive for my projects. But you can write your own implementation of the Identity UI. And I think, in a lot of cases, that's probably the best approach anyway.
Identity itself hasn't changed much. It's just the default template that has changed.
Is there still a way to scaffold MVC like Identity code when creating a new project?
No. But it's not difficult to modify to MVC. Scaffold a 2.0 MVC project and you'll be very close.
Per https://github.com/aspnet/Identity/issues/1825
Maintaining two versions of the same codebase (MVC and Razor Pages) is very expensive for us and there are no real benefits from having an MVC implementation compared to a Razor Pages version. Both flavors are fully in ASP.NET.
Guys, this is really nonsense. I don't know why you did this.
This documentation doesn't match the current reality. At step 2, you tell us to add this code to Startup.cs:
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
But (1) the new project already has a call to
services.AddDefaultIdentity<IdentityUser>()
.AddEntityFrameworkStores<ApplicationDbContext>();
and, (2) the new project doesn't have an ApplicationUser class, so your code doesn't compile.
Now we get to explore the following the rabbit holes:
Any clarification on what was intended for 2.1's version of this exercise would be a big help. Thanks!
@seejessicacode
- find what to use in place of ApplicationUser.
ApplicationUser
-> IdentityUser
- compares AddDefaultIdentity() and AddIdentity() to guesstimate which is appropriate going forward
- roll with AddDefaultIdentity() and hope it doesn't negatively impact later steps
No need to change from AddDefaultIdentity
per Changes to authentication code
when the docs would be updated?,what the hell you doing?
@pangjianxin Feel free to submit a pull request if you don't feel like progress is moving quickly enough on this.
Please update the docs, been ripping my hair on how to set this thing up.
Note to self. 40K PV
Most helpful comment
@pangjianxin Feel free to submit a pull request if you don't feel like progress is moving quickly enough on this.