-
ABP Framework version: v9.0
-
UI Type: Angular
-
Database System: EF Core SQL Server
-
Tiered (for MVC) or Auth Server Separated (for Angular): no
Hi ABP team,
I wanted to check a point, how is it enforced that users have unique username or email? Is this an application level check?
If I check the database, I can see that all indexes are created as non unique so in theory it could be possible to create two users with same username or email if it happens in the same time.
I did a quick check and Microsoft is adding a unique index for the username at least: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/customize-identity-model?view=aspnetcore-9.0#default-model-configuration
8 Answer(s)
-
0
Hi,
UserManager uses IUserValidator to check user.
See more:
-
0
Hi Berkan,
I checked the code but this are application level validations. Basically there should be some unique index on DB level in order to have 100% certainty that no duplicates can be generated
-
0
Hello,
If you want, you can add it to your application. However, we do not add it by default because when we add this constraint, soft deleted data or users belonging to the tenant must be unique, which is not a situation we want.
-
0
Hi Berkan,
Thanks for the reply. Of course, we are aware that we can add this protection ourselves, but I opened this topic since ABP is not guaranteeing this behavior ( unique users). I think you should probably update the documentation in this case and let users know that they have to think about this situation.
Regarding what you said with the soft delete and tenancy, in SQL you have filtered indexes, in the sense that you can say that a deleted user is not covered by the unique index ( where IsDeleted = 0 ). Also for multi tenancy, the unique index can be a combination of Username + TenantId.
-
0
Thanks for the reply. Of course, we are aware that we can add this protection ourselves, but I opened this topic since ABP is not guaranteeing this behavior ( unique users). I think you should probably update the documentation in this case and let users know that they have to think about this situation.
I will inform the relevant team member to consider this. Thank you for your suggestion.
Regarding what you said with the soft delete and tenancy, in SQL you have filtered indexes, in the sense that you can say that a deleted user is not covered by the unique index ( where IsDeleted = 0 ). Also for multi tenancy, the unique index can be a combination of Username + TenantId.
Yes, I agree, it could be. We can also consider that. As far as I remember, it was already like this in the old versions of ABP, but then we removed it due to some problems.
I am closing this issue for now, but I will definitely share what you said with my teammate and we will inform you here if necessary. Thank you.
-
0
Hello again, after a short discussion, we agreed on the following opinion:
https://github.com/abpframework/abp/issues/1181#issuecomment-497723988
-
0
Hi Berkan,
What do you mean that you agreed on the opinion? From what I see there was no followup on that task :))
-
0
Normally, developer should care if the entity is soft delete and apply index based on it, like b.HasIndex(e => new { e.Name, e.IsDeleted }).IsUnique();
However, this is also not the final solution. Think that you have deleted an entity named "Foo", then created another entity with name "Foo", then you can not delete it since there will be two deleted "Foo" in this case.
I didn't know b.HasIndex(e => e.Name).IsUnique().HasFilter("[IsDeleted] != 1"); usage, but it seems a good solution at least for some databases. However, I think this is not ABP's job and developer should care about it. We may create an extension method for HasFilter("[IsDeleted] != 1") at most and document it.
We agreed that this is not ABP's job and the developer should take care of it.
We are also considering the documentation, but
HasFilter(“[IsDeleted] != 1”)is not supported by all databases, so we do not plan to provide such an extension method for now. However, we can provide additional information for those who want to ensure that username or email is unique at the database level, but I am not sure how much it is necessary. Because ABP already guarantees uniqueness at the application level and already covers most scenarios. As a best practice, as you said, it should also be at the database level, but we cannot add it due to the above problems. Nevertheless, we will consider adding it as a note to the document. Thanks for your understanding.
