locked
AspNetRoleClaim dont have Guid Id RRS feed

  • Question

  • User1712504604 posted

    I am using identity when i do migration the table AspNetRoleClaim and AspNetUserClaim do not have Id as Guid both tables have int rest of tables such as AspNetUsers and AspNetRoles have Id as Guid

    ApplicationRoleClaim : IdentityRoleClaim<Guid>
    public class ApplicationUserClaim : IdentityUserClaim<Guid>
        
    public class ApplicationRole : IdentityRole<Guid>
    public class ApplicationUser : IdentityUser<Guid>
        
    public class AppDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, Guid,ApplicationUserClaim,ApplicationUserRole,ApplicationUserLogin,ApplicationRoleClaim,ApplicationUserToken>



    Tuesday, April 13, 2021 9:41 AM

All replies

  • User475983607 posted

    I do not understand the problem.  By default Identity uses a GUID keys not integers.  You must have initially configured Identity to use integer keys.  Perhaps start over. 

    Tuesday, April 13, 2021 11:00 AM
  • User1712504604 posted

    I do not understand the problem.  By default Identity uses a GUID keys not integers.  You must have initially configured Identity to use integer keys.  Perhaps start over. 

    Every Table in db has guid key instead of aspnetroleclaims and aspnetuserclaims they have int key
    do i need to add something extra in startup although i add below line related to identity

    services.AddIdentity<ApplicationUser, ApplicationRole>().AddEntityFrameworkStores<AppDbContext>().AddDefaultTokenProviders();
    

    Tuesday, April 13, 2021 11:04 AM
  • User475983607 posted

    Every Table in db has guid key instead of aspnetroleclaims and aspnetuserclaims they have int key
    do i need to add something extra in startup although i add below line related to identity

    This is the default schema.  You need to configure set configuration before the initial migration.

    https://stackoverflow.com/questions/37166098/how-to-make-ef-core-use-a-guid-instead-of-string-for-its-id-primary-key

    What is the benefit?

    Tuesday, April 13, 2021 11:23 AM
  • User1712504604 posted

    Ali.Sufian

    Every Table in db has guid key instead of aspnetroleclaims and aspnetuserclaims they have int key
    do i need to add something extra in startup although i add below line related to identity

    This is the default schema.  You need to configure set configuration before the initial migration.

    https://stackoverflow.com/questions/37166098/how-to-make-ef-core-use-a-guid-instead-of-string-for-its-id-primary-key

    What is the benefit?

    correct me if i am wrong i think by default identity uses int as primary key i wanna use guid thats why i put guid every table of identiy have guid as primary key except roleclaims and userclaims. i put the code in above reply if you want to see further code please let me know.

    Tuesday, April 13, 2021 11:45 AM
  • User475983607 posted

    correct me if i am wrong i think by default identity uses int as primary key i wanna use guid thats why i put guid every table of identiy have guid as primary key except roleclaims and userclaims. i put the code in above reply if you want to see further code please let me know.

    You are correct the roles and claims table have use an int and identity(1,1) column.  Why do you want to change to a GUID?  What problem does this solve?  

    Anyway, I'm pretty sure you'll need to configure and write a custom role and claim storage provider to use a guid.  The code you've shown affect the Application User not roles and claims tables.   

    https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity-custom-storage-providers?view=aspnetcore-5.0

    Tuesday, April 13, 2021 12:56 PM
  • User753101303 posted

    Hi,

    If looking at https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.entityframeworkcore.identityuserclaim-1?view=aspnetcore-1.1 the TKey is for the user id. It doesn't seems you can customize the pk Id for the row (my understanding being that it is what you are trying to do).

    But as pointed already does it really matter. For now it seems to be an underlying implementation detail which is not exposed at all by ASP.NET Identity anyway so from a rpractical point of view it would change nothing at all for you?

    Thursday, April 15, 2021 11:03 AM