The new social authentication providers build on the existing authentication provider base and as such work within that constraint i.e. the provider works by associating the authentication success with a DotNetNuke user i.e. authentication happens via the provider, but authorization is a function of DotNetNuke users. This is always a username which is the unique value within DotNetNuke (display names are configurable and do not need to be unique - and by default email addresses are not unique, but can be made so via a change in web.config) - some of the requirement to have a unique username comes from the fact that our users/profile/membership are based on asp.net's functions which use username as the unique key.

New functions such as use email address as username have to still use the username value, but can prefill it - AFAIR the code checks to see if the email is unique and if it is it copies it and uses it as the username (I believe only the part before the @ is used), if it is not there is a string function which creates a unique version (can't recall the details but think a randomized number is used with the first component of the mail. As such this is a UI/UX item (simplifying/reducing the number of registration fields) rather than a change to the underlying API.

Please note, this is still early days for "social" providers (most previous auth providers were for things such as active directory where email is not an expected field), and we will be enhancing them  -I know that the request to associate with an existing account is logged (i.e. you could register with facebook and associate with an exiting DotNetNuke user - i think it would also be good if you could associate with other social providers such as google - in this way we could log you in to the same account as long as you have a valid auth cookie still existing for one of the social services) - i have no idea when these enhancements will be done, but you can of course log enhancement requests to support.dotnetnuke.com (and if any of you are coders, submit code the same way [make sure you check the code supplied checkbox] so it can be considered)

Hi Mike and Cathal,

Thanks for replying - I appreciate that at times work gets in the way of us all doing what we would prefer to be doing :).

I can understand the approach of working with what you've got and making incremental changes in order to get something implemented that works in a reasonably short time frame. But I also believe there are times when that approach is detrimental to the long term health of a system, and you need to step back and say "you know what, if we carry on like this then it's going to just get messy, time for a complete change of direction".  And I strongly believe that this is one of those times.

From this post and others I have read I would conclude that the ground swell of opinion is that DNN should move to a system where all the possible methods of validating a login lead to a single user account. I would go as far as to say that you should consider abandoning the use of 'username' as a login method at all, and just make that field a randomly generated value in all cases that you use to link to the asp.net user authentication, but never expose to the end user. The email method should be the default login/registration method with the others optional. The end user should be free to link as many of the authentication methods that the site provides to his account as he chooses - the first one that he registers should be no more significant than any other.

Could you point me at where the enhancement requests are managed so I can lobby there? Also, I recently saw a 'vote for ideas' page that I can't find my way back to - again if someone could remind me where that is if this isn't already there I will add it so we can gauge more accurately the amount of community support. I appreciate that what I am asking you to do is re-engineer a fairly fundamental part of the system, and unfortunately I'm not enough of a asp.net coder to offer help. But I strongly believe (as you may have noticed :) ) that this is something that needs to be done for the long-term good of DNN.

Regards,
Graham