Is there any way to disable the unique and required values from the email property in the user by tenant filter? Why is it there, surely uniqueness by user username and password by tenant is sufficient? If they are not required, how do I remove them?
7 Answer(s)
-
0
Is there any way to disable the unique and required values from the email property in the user by tenant filter?
In general, it may not possible due to a limitation (feature) of the Required attribute. Related issue: https://github.com/aspnetboilerplate/aspnetboilerplate/issues/1274
Why is it there, surely uniqueness by user username and password by tenant is sufficient?
Email address can be used to login.
-
0
Hi Aaron,
I have worked with this for a while and come to the conclusion that this has to be a design fault. If the user is signing in with an email then the email is a username. The system, as is currently configured, demands a unique email as well as a username and a password and an identifier for a tenant. For an app based solution we have no need for an email and it is an unnecessary overhead. All of these required fields for a new user make the registration process difficult for an app user.
-
0
This is the same for Slack, Facebook, etc. It's also used for account recovery. This is suitable for most projects.
A workaround for your design decision is to generate a placeholder, e.g. 0000-0000-0000-0000@example_._com (where 0000-0000-0000-0000 is a NewGuid).
-
0
Sorry, Aaron, I disagree. To use a service securely we simply need the username and password, that forms the basis of authentication and authorization. To sign up for Zero we need to add first name, surname and email. Not only is this an unnecessary overhead but it also means we are keeping personal details on the user and thus brings us all of the problems with the General Data Protection Regulations (GDPR), due to come into force in May 2018 (FOR ALL ORGANISATIONS WORLDWIDE). Effectively, by forcing the system to keep personal data you are forcing ALL OF YOUR CUSTOMERS under the GDPR umbrella. If you keep to user name and password there are no personal details held in the system and there is no reason to consider GDPR. It's simply nonsense to tell us that in order to create a user in Zero we need username, password, email, first name and surname after which we will use only the first two properties for the purposes of authentication and authorization.
-
0
Every SaaS system I have ever used has required an email, this is industry standard. Faceboook, Google+, Discord, Slack, Mint.com, Turbotax... I literally cannot think of a single service that DOESN'T require a valid email.
Without email verification, how will you prevent a bot service from launching an attack on your site and flooding it with fake accounts? And Don't say reCaptcha (See this whitepaper: here.)
Also, what happens when a user forgets his password? How are you going to allow them to reset if you have no user information to otherwise identify him/her?
Moreover, without the ability to contact your users, how are you going to send them information and updates about your platform?
-
0
Thanks strix20, looks like I'm swimming against the tide here! If I conceded the need for an email I still don't understand why I also need Firstname and Surname.
Without email verification, how will you prevent a bot service from launching an attack on your site and flooding it with fake accounts? And Don't say reCaptcha (See this whitepaper: here.)
The system requires a unique voucher code tying each registration to a tenant, what would stop a bot service from launching an attack on your site and flooding it with fake EMAIL accounts?
Also, what happens when a user forgets his password? How are you going to allow them to reset if you have no user information to otherwise identify him/her?
The system registers the device along with the user. It is possible to use SMS or notifications in the same way as you would traditionally use email. This can be extended to use 2FA in the same way you would use email.
Moreover, without the ability to contact your users, how are you going to send them information and updates about your platform?
As stated before, by SMS or notification.
I guess i will have to concede on this one and simply add a false (unique) email, firstname and surname to each registration.
-
0
<cite>BobIngham: </cite> Thanks strix20, looks like I'm swimming against the tide here! If I conceded the need for an email I still don't understand why I also need Firstname and Surname.
Without email verification, how will you prevent a bot service from launching an attack on your site and flooding it with fake accounts? And Don't say reCaptcha (See this whitepaper: here.)
There's no compelling reason for names.. you could always remove the required attributes from the domain and app dto and script a migration to remove the db requirement.
<cite>BobIngham: </cite>
The system requires a unique voucher code tying each registration to a tenant, what would stop a bot service from launching an attack on your site and flooding it with fake EMAIL accounts?
If you require email verification, then a bot cannot simply flood registration and access, it must also generate real email addresses, register, obtain the verification from the email, and follow the link. This is a vastly more complex process to automate than simply filling in a registration form.
<cite>BobIngham: </cite>
Also, what happens when a user forgets his password? How are you going to allow them to reset if you have no user information to otherwise identify him/her?
The system registers the device along with the user. It is possible to use SMS or notifications in the same way as you would traditionally use email. This can be extended to use 2FA in the same way you would use email.
Moreover, without the ability to contact your users, how are you going to send them information and updates about your platform?
As stated before, by SMS or notification.
But SMS is no different than email is with regards to GDPR, so I don't understand how a phone number is a better requirement than an email. And it would still have to be required. In general, people are much less willing to give out their phone numbers than emails. I personally will not use a service that requires SMS / phone as a 2FA. Google Auth or email is fine, but my phone number is off limits.
Also, using a device is not an acceptable way of identifying a user. People use web apps from all kinds of places, schools, libraries, work, all of which are public. Add in mobile / laptop connections from unsecured public wifi, hotels, etc, and you can never trust a device as an identifying feature.
If you really want to mask emails from your users, then that should not be done at the application level, it should be the responsibility of the tenant admin to make that decision. If they don't want to put in live emails when they are creating user accounts for their users, they can use google aliases that are unique, and redirect to their admin emails.
