Using DotNetNuke for Zendesk single sign-on

ZenDesk Integration

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.

Some background

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.

http://www.interactivewebs.com/advancedlogin/DNNLoginModule.aspx

DNN Google Authentication Login

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.

1. Navigate to Admin > Extensions - OR – Go to an Extensions module.
2. Expand the Authentication Systems section.
3. Click the Edit button beside DotNetNuke Google Authentication Project.
4. Expand the Authentication Settings section.
5. At Enabled?, select from these options:
   • Check the check box to enable Google authentication.
   • Uncheck the check box to disable Google authentication. Note that any ID and Secret information you have added will not be removed from these fields unless you manually remove them. This allows you to re-enable this authentication system at any time without reentering this information. Skip to Step 8.
6. In the APP ID text box, enter the information provided to you by Google .
7. In the APP Secret text box, enter the secret code provided to you by Google.

8. Click the Update Authentication Settings link. The Google login button is now displayed on the Login page and any Account Login modules.

Using the Token in Advanced Login

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

Advanced Login Module Single Sign-on Community Edition

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:

Name

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.

Description

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.

Master Site

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.

An example:

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.

Authentication Domain

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

During the installation of the DotNetNuke Microsoft pivot module, it is necessary to several changes to be made to the web.config file. These changes allow the Silverlight pivot technology to operate on the DotNetNuke website.   
    
We have automated the installation process to automatically update the web.config file during the installation of the module.

Please remove the following things under <system.web>

<add verb="*" path="*.cxml" type="iwebs.Modules.Pivot.CXMLHandler,App_SubCode_Pivot" validate="false"/>

<add verb="*" path="*.jpg" type="iwebs.Modules.Pivot.TileHandler,App_SubCode_Pivot" validate="false"/>

<add verb="*" path="*.dzc" type="iwebs.Modules.Pivot.DZCHandler,App_SubCode_Pivot" validate="false"/>

<add verb="*" path="*userprofile.aspx" type="iwebs.Modules.Pivot.ProfileHandler,App_SubCode_Pivot" validate="false"/>

   Also the ones under </system.webServer>

<add name="CXMLHandler" verb="*" path="*.cxml" type="iwebs.Modules.Pivot.CXMLHandler,App_SubCode_Pivot" validate="false" preCondition="integratedMode"/>

<add name="JPGHandler" verb="*" path="*.jpgx" type="iwebs.Modules.Pivot.TileHandler,App_SubCode_Pivot" validate="false" preCondition="integratedMode"/>

<add name="DZCHandler" verb="*" path="*.dzc" type="iwebs.Modules.Pivot.DZCHandler,App_SubCode_Pivot" validate="false" preCondition="integratedMode"/>

<add name="ProfileHandler" verb="*" path="*userprofile.aspx" type="iwebs.Modules.Pivot.ProfileHandler,App_SubCode_Pivot" validate="false" preCondition="integratedMode"/>

<add name="TileHandler" verb="*" path="*_files/*/*_*" type="iwebs.Modules.Pivot.TileHandler,App_SubCode_Pivot" preCondition="integratedMode,runtimeVersionv2.0"/>

We have often receive lots of questions about Web-safe fonts, or web friendly fonts. We have products that work with technologies like Microsoft Word, and publish back to websites like DotNetNuke. (DNN Word Editor)

The issue is that not all fonts will work on all browsers on all computers. Here is the reason why.

Web-Safe Fonts

There are an awful lot of fonts in the world! For years, no doubt, you’ve been using a ton of them in word processing documents, party invitations, banners, etc. But have you ever noticed how few of them are used on the web?

There’s a really good reason for this. When a web page loads, the browser is told to write text onto the screen using a specified font—one that is stored on the computer that the browser is running on. Therefore, if the web page’s code is calling for a font that a user does not have installed on their computer, it won’t show up! What that person will instead see is a default font, which might look a little ugly.

Now you might be wondering why this will happen so often if there are so many fonts installed on your computer. Well, here’s the problem: the two most widely-used operating systems—Windows and Mac OS X—each come installed with a different set of fonts. Awesome!

To illustrate this point, here’s where the fonts are stored in Windows 7:

And here’s where they’re stored on Mac OS 10.6:

Right away, we can see that only one of the displayed fonts overlaps: Arial. None of the Calibri orCambria fonts are available on the Mac, and the Mac has at least a dozen just on this page that aren’t available in Windows!

In fact, between these two systems, there are only ten fonts that overlap:

Those fonts that fall into that middle area, covered by both operating systems, are what we callweb-safe fonts. If you use Calibri on your webpage, Mac users won’t see it; if you use Andale, Windows users won’t see it; but if you use Georgia, you can rest assured that users of both systems will see the it.

Now there’s a bit of grey area here. Users of older operating systems don’t have some of these fonts we’ve declared web-safe. For example, Windows XP users don’t have Palatino or Trebuchet MS. Even worse, users of Android mobile phones don’t have any of these fonts.

So to be clear, there are only five fonts that are considered universal:

• Arial
• Courier New
• Georgia
• Times New Roman
• Verdana

Feel free to use these fonts all you want! Even if you dug up that old Packard Bell you had back in 1997 and it didn’t explode when connected to the modern web, you’d be able to see these fonts rendered as intended. Those Android users will just have to fight for themselves.

Web Safe Fonts Table

*The green marks show very common fonts, the yellow shows not so common but all are generally accepted as web safe.

So, what happens when the font fails?

Your text will still be visible, but the browser will use whatever default font it supplies for situations like this. This means that you may have intended to use a cute, scripty font, but what you get is

Your text typed in a regular serif font.

This is good because your content still goes through, but your design might be compromised. Therefore, you should always specify fallback fonts and a category that the font falls into. Let’s say that you want to use Helvetica, but you’ll settle for Arial. Since both of these fonts are considered to be sans-serif fonts, you can write a CSS declaration like this:

{ font-family: Helvetica, Arial, sans-serif; }

The browser will first try to use Helvetica, and if it’s not installed, it’ll attempt to use Arial. If even that font is not available, it’ll use whatever default sans-serif font the browser likes, but at least it’ll be the correct type of font!

For more information about coding fallbacks, alternative methods to using non-web-safe fonts, and everything typography related, you can pick up a copy of our Web Typography Handbook. It’ll tell you everything you need to know.