Hello everyone.  I am in a situation where I need to add users into different portals with the same username but different passwords.  These are different users and there is no need in my implementation for a user from one portal to authenticate on a different portal. I'm currently using 3.2 and this scenario does not work, adding a user with the same username but different password fails with an invalid username message.

I am trying to determine if this is a Membership provider or a DNN limitation, or possibly just a DNN bug.  I spent some time looking at the UserController.vb,  the signin control,  the membership docs, and the stored procedures behind all of these functions and I don't see why this scenario wouldn't be supported.

From what I saw, all authentication happens passing in the PortalId, which is translated into the ApplicationId which make the username/password/applicationid  completely unique.  When adding users in different portals the data always seems to be stored with an ApplicationId that corresponds to the correct portal, so adding users seem to work as I would expect it.

The only place I see the problem is in the adduser routine.  It calls getuserbyname with a null portalid to check for a conflict with a superuser, which makes sense.  If it returns any rows, it also uses the membership validate routine to see if they are already registered in that portal.  That makes sense, but what doesn't make sense as why it fails at that point just because there is a username in another portal.

Is this a backward compatability issue?  Can anyone let me know what I'm missing or if they think it would be safe to rewrite that piece of code to allow the duplicates.

Thanks for any advice.  

Steve

By the lack of responses I'm guessing this hasn't come up much before.  Can anyone direct me to a dnn cosultant who has experience with the dnn membership.  I'd gladly pay a couple hours of consulting time to confirm I'm not going to make a huge mistake by changing the code to allow duplicates username in different portals.

I don't know why this was originally designed this way, as I did not do it.  However, I have classicly seen it as a potentially good thing rather than a bad.  My company does a lot with large organizations that have many locations.  We give each one of those locations their own portal.  This allows each location to have some autonomy but also be connected to the overall host.  A particular person may register in multiple locations and have different permissions in each portal.  However, it is useful for that user to have a single, common username throughout them all.  DNN forces this to happen because it will not let some other random person come in and register using a username that is already taken, unless it is the person who 'owns' that username and knows the current password.  We have used it sort of as a little universal identity system for a DNN host (like Microsoft Passport or AOL Screen Name Service). 

Now, the fact that it works this way is not very clear, and I would say the user experience should be less confusing.  I have seen the 'owner' of a username try to register on a new portal, and if they forgot their password on the other portal or happened to use a different one, they get very confused by the fact that the portal tells them the username already exists.  When they see that error, many people then backout and try to login, but that doesnt work of course because that username is not registered on the current portal.  I think that for this to work properly, the login and registration should be prompt the user with a different screen notifying the user that they are registered on a different portal in the 'network'.  If the password the entered is incorrect, they should be prompted to enter their correct password and allow them to get reminded of their password.  Once they do verify the password, they should be prompted as to whether or not they want to share their data from the other portal with the new portal.  There are other implications around branding the login as a common host wide 'xyz organization login' and some issues around the lack of management of a users profiles across portals, but overall, the current way the dnn membership operates does work in some situations.

For your situation, it sounds like these are totally seperate portals/organizations, and any sort of cross portal registration does not make sense, as each organization will want the own very unique identity.  If that is the case, I don't know of any way to configure DotNetNuke to not behave how you descibe without modifying the code.  I do know that there are some alternate Membership Providers out there.  They may allow you to do this, I don't know.  Perhaps someone else can chime in here if they know of another way around this.