Core Identity Documentation Updates #5889
Conversation
Pull from main
merge from docs
merge from docs
|
lmk if a sample of the Core project is valuable with a sample membership DB and migration script included |
|
@blowdart can you validate this is inline with what you want? |
|
bump to @blowdart @danroth27 |
|  | ||
|
|
||
| ASP.NET Core 2 Identity uses [Entity Framework Core](https://docs.microsoft.com/ef/core) to interact with the database that holds the Authentication data. In order for the newly created application to work, there needs to be a database to store this data. After creating a new application, the fastest way to inspect the schema in a database environment is to Migrate the Entity Framework Code First Schema to a database hosted either locally or elsewhere. Please review the documentation specified above for more information if interested. To create a database with the Identity Core Schema, run the following command `Package Manager Console`, which is located in **Tools** > **Nuget Package Manager** > **Package Manager Console** | ||
|
|
There was a problem hiding this comment.
Will people who have never used EF understand "Migrate the Entity Framework Code First Schema"? Should this be "create the database using Entity Framework migrations"?
| } | ||
| ```` | ||
|
|
||
| This command will "Seed" the database specified with the schema and any data needed for intialization of the application. The following image is the table structure that is created with the above steps. |
There was a problem hiding this comment.
seed, to me, means insertion of data, not the creation of the schema. The internet agrees. https://en.wikipedia.org/wiki/Database_seeding. So, not seeding. I don't think any actual data is created by default here.
|
|
||
| ## Migrating the Schema | ||
|
|
||
| Observing the table structure for both Membership and Core Identity shows there are subtle differences in the table names, and upon further investigation, the fields on said tables is different as well. The pattern has changed substantially for Authentication/Authorization with ASP.NET and ASP.NET Core applications. The key objects that are still used with Identity are **Users** and **Roles**. Here are mapping table for **Users**, **Roles** and **UserRoles**. |
There was a problem hiding this comment.
"said tables" -> "the tables", easier to understand.
|
Should we mention password hashing has updated, and they may want to consider just not migrating passwords at all, otherwise you're stuck with the older hash until someone logs in and it gets updated? |
|
@blowdart I put this in the text
Does that suffice? |
|
Leave as null, rather than blank. |
|
@blowdart I made the updates, let me know if anything else is needed. |
|
LGTM, sorry I took so long, I was ill last week |
|
@isaac2004 I have some word-smithing to do (style guide adjustments), and then I'll merge the doc. Aiming for later day. |
|
@scottaddie please don't merge, i still have to do the other part of this |
|
@isaac2004 Simply remove the [WIP] label and let me know when it's ready. |
aspnetcore/toc.md
Outdated
| ### [HTTP modules to middleware](xref:migration/http-modules) | ||
| ## [ASP.NET to ASP.NET Core 2.0](xref:migration/proper-to-2x/index) | ||
| ### [ASP.NET Membership Data to ASP.NET Core Identity](xref:migration/proper-to-2x/membership-to-core-identity) | ||
| ### [HTTP modules to Middleware](xref:migration/http-modules) |
| > [!NOTE] | ||
| > If the Membership system had users with user names that didn't match their email address, changes are required to the app created earlier to accommodate this. The default template expects `UserName` and `Email` to be the same. For situations in which they're different, the login process needs to be modified to use `UserName` instead of `Email`. | ||
|
|
||
| In the `PageModel` of the Login Page, located at **Pages** > **Account** > **Login.cshtml.cs**, remove the `[EmailAddress]` attribute from the *Email* property. Rename it to *UserName*. This requires a change wherever `EmailAddress` is mentioned, in the *View* and *PageModel*. The result looks like the following: |
There was a problem hiding this comment.
**Pages** > **Account** > **Login.cshtml.cs**
*Pages\Account\Login.cshtml.cs*
| |`PhoneNumber` | string | `aspnet_Users.MobileAlias` | string | ||
| |`LockoutEnabled` | bit | `aspnet_Membership.IsLockedOut` | bit | ||
|
|
||
| **Note**: Not all the field mappings resemble one-to-one relationships from Membership to ASP.NET Core Identity. The preceding table takes the default Membership User schema and maps it to the ASP.NET Core Identity schema. Any other custom fields that were used for Membership need to be mapped manually. In this mapping, there's no map for passwords, as both password criteria and password salts don't migrate between the two. **It's recommended to leave the password as null and to ask users to reset their passwords.** In ASP.NET Core Identity, `LockoutEnd` should be set to some date in the future if the user is locked out. This is shown in the migration script. |
There was a problem hiding this comment.
Use the > [!NOTE] syntax here, as was done earlier in this doc.
| @@ -74,6 +77,7 @@ The host and application have been decoupled, which provides the flexibility of | |||
| **Note:** For a more in-depth reference to ASP.NET Core Startup and Middleware, see [Startup in ASP.NET Core](xref:fundamentals/startup) | |||
There was a problem hiding this comment.
Use the > [!NOTE] syntax here.
| @@ -74,6 +77,7 @@ The host and application have been decoupled, which provides the flexibility of | |||
| **Note:** For a more in-depth reference to ASP.NET Core Startup and Middleware, see [Startup in ASP.NET Core](xref:fundamentals/startup) | |||
|
|
|||
| ## Storing configurations | |||
| An important goal when building large, scalable applications is the loose coupling of components and services. [Dependency Injection](xref:fundamentals/dependency-injection) is a popular technique for achieving this, and it's a native component of ASP.NET Core. | ||
|
|
||
| In ASP.NET applications, developers rely on a third-party library to implement Dependency Injection. One such library is [Unity](https://github.com/unitycontainer/unity), provided by Microsoft Patterns & Practices. | ||
| In ASP.NET applications, developers rely on a third-party library to implement Dependency Injection. One such library is [Unity](https://github.com/unitycontainer/unity), provided by Microsoft Patterns & Practices. |
| @@ -128,7 +133,8 @@ The repository can be injected anywhere, as was true with Unity. | |||
|
|
|||
| **Note:** For an in-depth reference to dependency injection in ASP.NET Core, see [Dependency Injection in ASP.NET Core](xref:fundamentals/dependency-injection#replacing-the-default-services-container) | |||
There was a problem hiding this comment.
Use the > [!NOTE] syntax here.
|
Thank you for your help, @isaac2004! |
|
Would not have gotten there without your help @scottaddie |
Fixes #6192
Fixes #974
Fixes #4237
Based on Feedback from #974 & #4237 this PR will be an update to the structure of the Migration node to better lay out migration documentation for Authentication and Authorization. This is the scope of the PR
@blowdart can you review the doc that I added on membership? Goal is to show users how to migrate the schema.
Internal Review Pages
Migrate from ASP.NET Membership Authentication to ASP.NET Core 2.0 Identity