You might be well aware that DNN allows you to create multiple Portals based on the same physical installation and the database. It even allows the users to be managed independently across Portals, restricting users to the Portal they registered for.
However, there is a less publicized aspect of this feature of DNN. Let’s see it in action before I desribe it theoretically. For this, you would need a DNN installation with atleast 2 portals on it (the Parent/Child status of the Portals does not matter). If you dont’ have it, first create a test installation with 2 portals. Keep the registration public on both. I will call them http://p1.com, and http://p2.com, for this example.
Browse to http://p1.com, and click the Register link. Create a dummy username say “test”, and give any password (but remember it). Let’s say your password is “master”. Login to the portal http://p1.com with your username, test. You see everything works normally.
Now logout of p1, and browse to http://p2.com. Again click the Register link. Give “test” as the username, but give some other password, let’s say “second”. When you click Register, notice that DotNetNuke shows you an errors, and does not create your account. No matter, what you do, if you want to register with username “test” on http://p2.com, the password provided should be “master” (the one we provided for p1).
Now the above leads to a very major conclusion. There is an implicit built-in assumption in DotNetNuke, that 2 users trying to register with the same username on 2 portals on the same installation, are actually the same human (or bot, if your site is not protected against automated registrations).
Thus, 2 different people cannot use the same username on different portals of the same installation.
There are some other extentions also to this aspect. Although DotNetNuke allows you to maintain your Profile per portal, but your username, password, first name, and last name are uniquel maintained across multiple portals, meaning that if you change them on one portal, the changes are automatically reflected in the other portals.
This last point is important. If you change your pssword on one portal (or username/first name/last name), they are changed across all portals.
Physically this is so, because these values are not stored per portal but once in the Users/aspnet_Membership tables.
Logically, this makes sense to me, as I would normally expect different portals on the same installation to be related to each other in some way.
Thanks Rahul for this information. I am building multiple member sites on the same installation and a number of users will need access on more than one site. I am sure they will complain if they had to have a separate username for each one. Now, if I just be sure to set them up with the same password, they can access each of their sites with the same user name. This was very helpful. Regards, Clark.
I just read your article and to my surprise i wasn’t able to create sites for my customers with their own admin (login “admin” password “blabla”)
I use a single instance of DNN and am looking for a module that enables me to use a single instance but for every portal created a separate user thingy.
so: i login in p2 and am able to create another admin account.
Although i can see why one login for multiple portals is great, i don’t want it to work that way and i also dont want to install separate instances for every set of users.
Do you know a module (or something) that makes this possible?
“I had to create a new Profile Provider as the solution, which ensured that Profile Properties are also synchronized across portals, and change in value of a property on one portal are reflected across others.”
We have this same problem. Is your solution available to us?
Thanks! That would be great
Cheers! Happy New Year!
i have facing the problem in dnn,
i have not login in portal 0 but i can login in my others portals site
same username and password ?
Can I have the user accounts appear globally with two parent portals? Example…I have two parent portals, however the portal 0 has all the users that registered but they are not in the second parent portal.