Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModules404 error when accessing Apple file links (.pages and .numbers)404 error when accessing Apple file links (.pages and .numbers)
Previous
 
Next
New Post
12/6/2017 10:49 AM
 

Just recently I came across an issue with file view/download with DNN.

It all started when I added iWork file extension (.key, .pages and .numbers). From my understanding, these extensions are Apples fancy way of packaging content in a zip file with custom extension.

I have been trying to troubleshoot this issue for two days now at first thinking this is an issue with IIS. So, long story short I managed to narrow down the problem to file extension length. To be precise to char length of 4. So, if I trim extension to .page or .numb DNN can serve those files with no issues. Obviously .key being only three chars long doesn't have the same issue.

Now I am looking for anything inside DNN that could be responsible for limiting or filtering request based on file extension length. Help in this matter is greatly appreciated.

 

To help with troubleshooting the issue:

  • I am using DNN v7.4.2 running on IIS 7.5.
  • I added .key, .pages, .numbers to the list of Allowable File Extensions in HostSettings.
  • I added following MIME maps to IIS:
    • .key
      • application/x-iwork-keynote-sffkey
    • .pages
      • application/x-iwork-pages-sffpages
    • .numbers
      • application/x-iwork-numbers-sffnumbers
  • Using DAM to upload and download files i get the following results:
    • No issues downloading (default behavior) keynote files
    • 404 error for pages and numbers
    • No issues with .page or .numb files
  • I know is said DAM above but the issue is not limited to DAM. Journal and a few other modules all display the same issue.
 
New Post
12/6/2017 12:02 PM
 

Update

It just so happens that I had a clean local install for DNN 7.1.1, 7.4.2 and 9.1.1. That got me thinking. Let's see if I can replicate the issue in any of the clean installs.

Test procedure:

  • Got a clean install of DNN 7+ on the same IIS
  • Added .key, .pages and .numbers to list of Allowable File Extensions in HostSettings
  • Using DAM (Admin > File Management page) uploaded one of each (.key, .pages, .numbers) - no issues
  • Downloaded (default behaviour for file type) all three files - no issues

This further narrows the list of culprits to a specific install where I am currently experiencing this issue. This leaves three possibilities:

  1. DNN miss configuration
  2. Something got skewed during one of the previous upgrades
  3. On a slim chance I could have screwed something in DNN core
 
New Post
12/6/2017 12:02 PM
 

Removed: double post - this module needs a fix

 
New Post
12/6/2017 4:05 PM
 

Update

Still no luck resolving the issue but I do have something to report.

I found the class responsible for handling requests for LinkClick.aspx and this is what I have so far:

    var directUrl = fileManager.GetUrl(file);
    if (directUrl.Contains("LinkClick") || (blnForceDownload && folderMapping.FolderProviderType == "StandardFolderProvider"))
    {
        fileManager.WriteFileToResponse(file, contentDisposition);
        download = true;
    }
    else
    {
        context.Response.Redirect(directUrl, /*endResponse*/ true);
    }

Journal module uses LinkClick.aspx request to serve files. In my case, the FileManager returned a direct URL to the file which according to the logic forces a redirect. The redirect fails with ThreadAbortException and I get Error 404. Using the above logic to my advantage I set my links to get generate with ForceDownload flag. So when I click on the link I get a prompt to save file.

Now I ma looking for code that is responsible for processing requests to see what kind of logic is responsible for my Error 404.

 
New Post
12/7/2017 10:22 AM
 

Update

I found what limits files extensions to four chars. To find the answer one needs to go digging in ProcessRequest method found in AdvancedUrlRewriter.cs. Close to the very end of try-catch-finally block we have the following:

    if (result.DoRewrite == false && result.CanRewrite != StateBoolean.False && !finished && result.Action == ActionType.Continue)
    // result.DoRewrite = false
    // result.CanRewrite = NotSet
    // finished = false
    // result.Action = Continue
    {
        ...
        //if (!pathWithNoQs.Substring(pathWithNoQs.Length - 5, 5).Contains("."))
        if (!pathWithNoQs.Substring(pathWithNoQs.Length - 5, 5).Contains(".") && !pathWithNoQs.EndsWith(".pages") && !pathWithNoQs.EndsWith(".numbers"))
        {
            ....
        }
    }

Bumping the numbers to 8 or being a bit more specific satisfies this checkpoint and voila I get a prompt to save the files.

However, that still doesn't answer why the same issue doesn't affect three other instances of DNN that I have locally.

Something else worth noting

In web.config if I change friendlyUrl node and set urlForms="humanfriendly" instead of "advanced" the files get served without the adjustment to the core. But it breaks all custom navigation on the site. In addition you you're suing social login providers and I do (namely Azure and Google) I would have to change return url otherwise the users don't get returned back to the site when they try to sing in. And lastly you also get explicit /Default.aspx at the end of each url that doesn't end with .aspx.

 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModules404 error when accessing Apple file links (.pages and .numbers)404 error when accessing Apple file links (.pages and .numbers)


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  


Copyright 2018 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out