suggestions to simplify username and other user information

[JustCallMeAD]

I have a few sugeestion about the user details in oqtane.

1. Remove the username and default to just having an "email address" and "password" (no username). Not only does asp.net core identity use an "email address" and "password" by default (which most devs will be used to) most modern apps (facebook, google, microsoft etc) do not have separate usernames anymore either. Everyone remembers their own email address but sperate usernames are easily forgotten and are just a pain in the butt.

2. Email addresses / usernames should not be locked - they should be changeable (having "host" as the default username is also a security risk as it is known to everyone).

3. Id's should be GUID’s so they are not easily guessed and people don’t know how many users / records you have. For example – if I was running a SASS app using oqtane then currently anyone could easily register a new user and then look at the id of that user and be able to find out many users my app has. Asp.net core also users GUID’s by default so again this would make oqtane more compatible with the rest of the asp.net eco system.

4. Remove other unnecessary fields like “Full Name” and “Photo” because most apps would not use them by default but devs can always add them later if they wish. Keeps it simple – “Email address” and “Password” are the only fields most apps use these days to sign up and if devs require other information from the user then they can always add it themselves.

Looks like a great project btw!

[sbwalker]

The changes described would have major impacts throughout the entire framework and would result in significant breaking changes to the API, so they are not something which could be considered at this stage. That being said, there may be some specific non-breaking enhancements which could be derived from your description above that could be discussed.

[JustCallMeAD]

Fixing security issues, information leakage and consistency with modern design patterns / best practices while the project is still new and not really used much in production will only help to strengthen the project and help build a better platform for everyone.

Although there will be some breaking changes, in reality the impact of those changes will be extremly low at this stage of the project as there is not many people using or building custom modules for oqtane. Better to fix or improve as many things as possible before you get a large influx of users which will make simple things to fix now, impossible to fix in the future.

[sbwalker]

Respectfully, although I appreciate your opinions, I will have to disagree with you. Based on my experience building platforms it is nearly impossible to get any adoption from developers until it is 1) stable, 2) backward compatible, and 3) upgradeable from release to release. Oqtane was first released on Github in June 2019 ( after 6 months of internal development ) and was in beta for almost a year until the 1.0 release in May 2020. It is only in the last couple months that momentum has begun to accelerate - and this is directly related to the 3 aspects I expressed above. And it makes logical sense - why would anyone build a house on a foundation if they knew it could change substantially and require them to rebuild their house? So we will be adhering to the non-breaking philosophy for the foreseeable future and focus on building a healthy community and ecosystem around Oqtane. However, as I said above, some of the non-breaking changes you outlined could certainly be considered. Plus there are plenty of ways using the existing extensibility options for you to work around some of the other items.

[JustCallMeAD]

Thanks Shaun for your response and I do agree with you that having a mature and stable platform without breaking changes is always best. So, I think we are in agreement there.

Please note that I was not suggesting that after the platform gets tons of users, modules and themes built around it that we should make breaking changes to it. All I was suggesting is that while there is basically no one using the platform in production then this is the perfect opportunity to fix some important things while we still have an opportunity to do so.

This is the last real chance we have to make changes without affecting tons of users (if any at all - are there actually any live sites even using Oqtane yet?) as once the platform gets widely adopted, as you know, making breaking changes should be avoided wherever possible. By doing as much as we can, while we still can, it will help with the “stability”, “backward compatibility” and “upgradeability” of the entire platform for the future.

I will leave this discussion here but if there is anything (breaking or non-breaking) in my suggestion that you would like to investigate further then feel free to reach out and I am happy to help wherever I can.

[thabaum]

Security is a huge concern here for me. Version 2 I was hoping to really push for security features enhanced. I was concerned about this prior to v1 release but the release time was more important.

I can't see allowing someone to fire up Oqtane now as website web app and expect security to be focused on... it is not going to be used. I need to develop all the security features into it.

removing fields from Oqtane Components as a developer is fairly easy, maybe an admin component can help choose what fields are important if someone has a PR to share so the less important ones can be removed if desired.

I agree and have been thinking the same as @JustCallMeAD with regards to who would actually just use Oqtane out-of-the-box Only super developers that have time to put into making all the security changes desired, a general user would look at this right now and take a step back if they are at all concerned with security.

To me this is a template to save time and if security is not a priority, I pass for production use until it is or I can develop what is missing.

Like @sbwalker mentioned... Blazor is still in RC mode. .NET 5 things will be more concrete on how to deal with security for long term, and you dont want to layout a 3 bedroom house foundation until you have the design for where to form it.

• Ability to edit username is good to have and could be added now
• ability to have email address as username I also think could be added to v1, an admin switch for one, the other or both is my preference here as everyone has their own "ease of use" for the purpose of the app. Also phone numbers and SMS messaging and 2FA are things that need to get in the works I plan to do eventually for myself and when I do I will share it. But dont let me get in the way of your PR if you have one for a solution please share. I will be able to focus my resources in other places then ;)
• GUID instead of userID - you would need to create a switch to allow to use one or the other so it is not a "Breaking Change" for everyone. And make GUID the default for new installations, but some way to allow UserID to go to GUID and visa-versa to allow a switch from the old way to the new recommended more secure way if desired I would think a PR like that would get accepted v1 as well.

v2 can have more breaking changes however it is still a bit of a dance with the community on things like this.