There seems to be surprisingly little discussion on what seems to me an important topic and one which, IMHO, is being implemented in a manner that seems to me way off the mark. An apology if this is a topic that is already on the forum, however I have not found an existing discussion. If there is one perhaps someone can point me at it in a reply and I will contribute there instead.
I am referring to the addition of new login providers with the advent of DNN 6.2. The only posts I have found about it is this: http://www.dotnetnuke.com/Resources/F...
And this
http://www.dotnetnuke.com/Resources/F...
There are two aspects which concern me about how this is being approached by the developers at the moment:
- 1. The implication that each login provider (twitter, Facebook, Google ) etc. creates its own user identity in the system when used to register
- 2. The inability to upgrade an existing site to 6.2+ and allow the use of an alternative login provider for existing users.
Why does this concern me? Simple, because not only does it not help with what is, to me, the biggest single issue with using DNN in the real world, it actually makes things worse. What is the biggest real-world issue? Once again simple, the fact that ordinary people (not us nerdy-type system administrators) CANNOT remember their username and password. That’s it, full stop. I’ll repeat: The biggest issue any my customers have with their DNN sites is that their end-users consistently fail to login as they don’t remember their user name.
Visualise it from the end-users’ point-of-view: they arrive at the login page and have to think “is my login on this site my first name, my surname plus initials, my email, something else?” Now think what happens if they get there and now there’s a Facebook option, Google option and so on. Not unreasonably, they would expect each of these options to be useable and lead to the same result –they get logged on as the same person. And this is not what has been implemented– instead they are going to have to remember not only a username but also which method they used to register – which is why I say this makes things worse not better. Most of them will inevitably finish up with multiple accounts on the site only one of which will be the ‘real’ one and have the correct security roles.
My heart lept with joy when I found the ‘use email address as username’ setting on my first DNN 6.2 test site. “At long last”, I thought, an answer. Wrong. I turned it on, went to login (in a separate browser, I’m not daft! :) ) typed in the email for my admin account and got rejected. I had to type in the username instead, not the email. So then I registered a new user – and sure enough I was only offered email and was only able to login that user using email. A quick glance at the Users table revealed why – all accounts before the setting change had a username and an email – any account created after had only a username (in email format) copied from the email address.
Here’s how, IMHO, it should work. A user account should be identified by a single primary key – the UserID. Each of the available login methods (and any new ones you add) should have a column (or columns if necessary) in this table that records the details for that method for that user. The profile should have the ability to have associated with it the login details for each login provider implemented on the site. The username column just becomes another provider’s login details column, not a key field in its own right as it seems to be at present. Regardless of which login method a user chooses they get the same account.
I believe it is absolutely essential that this or a very similar approach be implemented ASAP, otherwise we are just going to finish up with a dog’s breakfast solution.
Comments please – and if this is not the right stage how do I present this view to the development team?