It is technically possible to remove templates or login tokens from the module and lock yourself out of the website. The module has protection from this event in two ways.
If the module detects that you are updating the module settings and have totally removed the templates, it will detect this state and use a default template when accessing the front end of the module.
Additionally if you were to access your login page with this module on, and found that you do not have any buttons to press for access, you can revert to a login protection mode by adding some text to the URL. This will force the module to display some basic login details.
Just add: “?loaddefault=true” (without the “”) to the URL with the module on it. So as an example if you have the module on the home page you would use:
This will load the default template shown above.
This ensures that the Advanced Login module for DotNetNuke will not lock you out of your site and prevent you from logging in.
http://www.zendesk.com/ Zendesk is an online ticketing system designed to manage support tickets through a website interface. Zendesk is one of the more popular ticketing systems available as a software as a service.
We have included within the advanced login module the ability to login to Zendesk using your DotNetNuke user database. This makes it possible to manage all of your user support tickets for your DotNetNuke website within the Zendesk software as a service ticketing system, without having to have a separate database if users.
Configuration of this system is extremely easy. There are two settings required one is within the Zendesk interface, and naturally requires you to have signed up for services with Zendesk.
The other is within that advanced login module for DotNetNuke.
Zendesk allows you to configure a remake URL that is referenced logging in. There should be a URL on your website that has an instance of the advanced login module installed on the page. That instance of the module needs to be configured to work with Zendesk.
When a user clicks on the login button at Zendesk they are redirected to the URL mentioned above. They login to the DotNetNuke website with the normal advanced login interface of your choice. They will then be redirected back to the Zendesk helpdesk having been authenticated through your DotNetNuke user database.
Setup a page with the advanced login module installed. We recommend that you use the page that is the default login page the DotNetNuke. We have explained elsewhere in the manual how to configure this page with an admin only view of the normal all standard DotNetNuke login module, and included in instance of the advanced login module. You can then define in the administrator settings of your website to use this to find page as the login page for your website.
This does not prohibit you from using the advanced login module with more advanced modes like slide down or pop-up effect on other pages of your websites, but it does ensure that should anyone be directed to the normal login page DotNetNuke that they are presented with an instance of the advanced login module. This is the instance that will be used to configure the Zendesk settings.
Some of the great advantages of using DotNetNuke as your authentication provider for Zendesk, include the ability to integrate deeply your Zendesk ticketing system directly into your DotNetNuke website without having to cross over your user database.
Additional information is available from our website in the support page user manual.
Recently DotNetNuke launched the ability to configure Google authentication for login to your DotNetNuke website. This feature made its debut in DNN 6.2
we have updated the advanced login module to include the ability to use a token to display login options for the Google authentication system that is available in DotNetNuke 6.2 .
The utilisation of the token requires you to preconfigure your DotNetNuke website with the Google authentication provider. A good description of how to do this is available here:
How to enable or disable the DotNetNuke Google authentication system that allows users to login to DNN using their existing Google account to login to DotNetNuke.
Prerequisites. You will need to sign up for a Google Authentication account to complete this tutorial. This authentication system must be enabled by a SuperUser (see "Managing Authentication Systems") before it can be viewed and configured.
8. Click the Update Authentication Settings link. The Google login button is now displayed on the Login page and any Account Login modules.
After you have correctly configured DotNetNuke to allow the Google authentication provider. You may use the new token within the advanced login module templating system.
The token is: [login_google_button]
Which simply places button on the login page indicating that the user can utilise the Google login system.
Nothing could be simpler.
Additional information about the DotNetNuke advanced login module please visit: http://www.interactivewebs.com/advancedlogin
today we are please to announce that the advanced login module for DotNetNuke includes the utilisation of the single sign-on feature that has previously only been available to the Professional Edition since DotNetNuke 6.1.
Now it is possible to add this feature to your website with one simple module, that as the feature throughout your entire website and child websites on a single DotNetNuke instance.
The idea is that you create a site group, specifying the master site and included child sites. Once the configuration has been created, a user will be able to login to either the Master site or any of the specified child sites within the group using the username and password details from the master sites user database.
We have included this feature within the advanced login module, and it works with the community edition. The feature can be found on the tab called site groups:
This is a descriptive field only and is used to distinguish one site group from another. You can put anything you like in this field that will help you remember the details of the site review are creating.
This is an additional descriptive field that allows you to put text that helps you explain the meaning behind the creation of the site group you are creating. This is a reference field only and can contain any descriptive text.
The master site is the primary site that contains the user names and passwords that you wish to use to sign on to either the Master site or the child portals. It is vital that you select the correct portal to use as the Master site.
InteractiveWebs is a DotNetNuke website that has one master portal that we used to run the interactive webs website on, and dozens of child portals. Each child portal is used to represent one of the modules that we have created the DotNetNuke. There are lots of them.
When users register on the interactive webs website they are registering on our primary portal. When users visit the child portals information on a module or other service that we provide we do not encourage them to register as users on his child portals. As a matter of fact we had previously redirected the login buttons back to the primary portal so that anybody wishing to register or login is always directed back to the primary portal. This means we have an extensive user database on our primary portal.
So in this example we would definitely need to select the interactive webs primary portal as the master site as it is this site that has all of the thousands of usernames and passwords that we wish to use across all of our child portals.
The authentication domain is the domain name that is used primarily across all of the portals that the site group is using. In the case of interactive webs, we have utilised a conical redirection within the site alias settings to ensure that users of our portal remain on the same domain: interactivewebs.com even though we have multiple domain names pointing to the website.
For more information: http://www.interactivewebs.com/advancedlogin