iFinity

We are experiencing a problem with Url Master 1.15.1 and DNN 5.2.2.

If a url is entered that refers to a tab on a different portal, the following error appears:

500 Server Error

My expectation would be that the url should be ignored and the browser remain on the current page if an invalid tab is entered.

For example, if you enter "/default.aspx?tabid=123456789" it is handled in a user friendly way and just ignored. The browser remains on the current tab.

However, if you enter a url for a tab that exists in different portal (e.g. "/default.aspx?tabid=802" on our site) you get the exception.

I have had a look at the code in reflector and can see where the problem lies....

Let's look at the ImprovedFriendlyUrlWithMessages method in the DNNFriendlyUrlProvider class

public static string ImprovedFriendlyUrlWithMessages(TabInfo tab, string path, string pageName, string httpAlias, bool ignoreCustomRedirects, FriendlyUrlSettings settings, out List<string> messages)
    {
      string friendlyAlias = path;
      friendlyAlias = GetFriendlyAlias(path, httpAlias);
      friendlyAlias = GetFriendlyQueryString(tab, friendlyAlias, pageName, settings);
      PortalAliasInfo portalAlias = new PortalAliasController().GetPortalAlias(httpAlias, tab.get_PortalID());
      PortalSettings portalSettings = new PortalSettings(tab.get_TabID(), portalAlias);
      friendlyAlias = ImproveFriendlyUrlWithMessages(tab, friendlyAlias, pageName, portalSettings, ignoreCustomRedirects, settings, out messages);
      return ForceLowerCaseIfAllowed(tab, friendlyAlias, settings);
    }

The problem occurs when the PortalID in the tab parameter is different from the portal referred to by the httpAlias. This results in portalAlias being set to null.

            PortalAliasInfo portalAlias = new PortalAliasController().GetPortalAlias(httpAlias, tab.get_PortalID());

This of itself is not a problem, but the following line is the problem since it attempts to instantiate portalSettings with a null portalAlias.

            PortalSettings portalSettings = new PortalSettings(tab.get_TabID(), portalAlias);

This causes a NullReferenceException within the PortalSettings constructor as can be seen below:

Public Sub New(ByVal tabID As Integer, ByVal objPortalAliasInfo As PortalAliasInfo)
            _ActiveTab = New TabInfo

            PortalId = objPortalAliasInfo.PortalID   ' *** exception thrown here because objPortalAliasInfo is null
            PortalAlias = objPortalAliasInfo

            Dim controller As New PortalController
            Dim portal As PortalInfo = controller.GetPortal(PortalId)

            If Not portal Is Nothing Then
                GetPortalSettings(tabID, portal)
            End If
        End Sub

So, my request is can the DNNFriendlyUrlProvider be updated to handle urls that point to tabs in different portals in a user-friendly way.

Is this a suitable request or am I missing something in the above examples?

Thanks,
Jonathan

Yes, your portal a/b example is exactly what is happening. This occurs because old urls still exist on other websites, in user's emails or browser bookmarks.

I agree that these urls cannot be constructed. My request would be that this scenario is handled in a way that doesn't cause an exception.

I see two options.

1)  Ignore the request and remain on the same page (or go to the home page if not already on the site). This is current behaviour if you request a tabid that did not exist.
2)  Generate a 404 Not Found error since these are bad urls.

It would be nice to have a Url Master site setting that determines the behaviour when requesting cross-portal tabs. i.e. ignore request or generate 404.

Thanks,
Jonathan

OK, I've installed the new version and the errors have stopped, however the behaviour is not what we were wanting.

Users are clicking on OLD urls. We need Url Master to handle these in a clean way as described in the original post (either ignoring the url and staying on the site, or giving a 404).

The updated version is actually displaying old tabs and content that we do not want displayed.

The original problem was not that the users were on the wrong portal, but that the urls were old/invalid. So, trying to automatically change the portal has acutally created a new problem. Is it possible to implement the user-friendly response that I described in the original post (either ignoring the url and staying on the site, or giving a 404) ?