Hello:  

It sounds like you can accomplish this by creating two websites on the same DNN instance. 

Then, you'd want to have some sort of routing or rules in place to be sure that only those who should see the "admin" site will be able to. 

This can be done a number of ways, but I'd suggest using two redundant methods.  In this case, I'd first look at applying a <code>redirectRule</code> in the web(dot)config, and another in your website firewall.  This way, if one fails for any reason, the other is still in place.  

Once you have the two sites created, you'll want to link them using the Site Groups feature in the persona bar.  This will allow you to have and use shared content between the two sites.  This way, you can either have "primary" copies of the content on the admin site that feeds the public site, or...  You can have the two sites be duplicates and still do the same thing.  In this case, though, it would be easier to know and see what the impacts of the changes would be since the site is an exact copy. 

(The first example would be faster, using a utilitarian (back-office) approach where you'd simply see content everywhere to edit, without the context and design.)  

As you build out the "admin" site, you'd begin adding an existing module to the "public" site.  As long as the two sites exist and they're grouped, you'll be able to select modules from the "admin" site to place as a linked copy on the "public" site.  

The big caveat here is that you need to be very selective when building and choosing modules for this kind of implementation.  They need to support content sharing.  You should be able to reach out to the respective vendor(s) for any third-party/custom extensions you plan to use and ask them.  

Good luck!  

May I ask what would be the problem with just hidding the login control and/or using a custom login page, with the link hidden?

It seems to me that you don't need that much complexity.

The default behaviour is that non-logged in (anonymous) users can only view. Then you can provide suitable accounts for the people/person who makes the changes.

So long as it's OK for anonymous users to see the login page this will do everything you want. If a user has no account then they can't login.

I don't know if this is any such case, but some corporate sites have the separation of responsibility by website as a requirement. As the others mentioned, it's also possible to just prevent logging in, but that should also be done using multiple (redundant) methods to ensure security - assuming that security is the true requirement here.

There is another possibility to accomplish this if you need to devide the two websites completely in different folders, but it is a bit tricky, and since a while the DNN installer has no more interface for that.

The idea is to use a so called "Object Qualifier", at least for one site. This has to be defined before the start of installation, by setting the objectQualifier attribute in the web(dot)config file.

<code><add name="SqlDataProvider" type="DotNetNuke.Data.SqlDataProvider, DotNetNuke" connectionStringName="SiteSqlServer" upgradeConnectionString="" providerPath="~\Providers\DataProviders\SqlDataProvider\" <span style="background-color:yellow;">objectQualifier=""</span> databaseOwner="dbo" /></code>

The object qualifier is a string, e.g. "site2". What it does is it puts the string in front of the database objects, the table "Users" becomes "site2_Users", the stored procedure "GetAllUsers" becomes "site2_GetAllUsers" etc.

This explains the specific SQL syntax in DNN installation scripts or the SQL Console, like

<code>SELECT * FROM {databaseOwner}<span style="background-color:yellow;">{objectQualifier}</span>Users</code>

Happy DNNing!
Michael

ObjectQualifier was removed from the UI for the main reason that so many modules did not support this properly. So if you do plan to go that route, be aware that it would be a bit more brittle since not much testing is done in that "deprecated" scenario.

Thanks Daniel, I did not know it is "deprecated".

Happy DNNing!
Michael

Posted By Michael Tobisch on 3/8/2024 1:03 AM
Thanks Daniel, I did not know it is "deprecated".

Happy DNNing!
Michael

Yeah, it will be removed at some point in the future, but I still make sure to include it everywhere until then.  Just in case...  

 

Posted By Michael Tobisch on 3/8/2024 4:03 AM
Thanks Daniel, I did not know it is "deprecated".

Happy DNNing!
Michael

 

Yeah, so "deprecated" is a big word and we don't have a nice way to migrate forward migrating sites that use it. So it could be supported forever but let's say it is not recommended :) It was useful at a time when having more than one database would incur expensive hosting.