RFC: Don't expose file last modifed date/time via cachebusted URLs

[roman-yagodin]

Description of problem

Currently raw file last modifed date/time is used to produce cachebusted file URLs, like http://mysite.com/myfile.pdf?ver=2018-04-20-144725-343. I thinks there are cases then we do not want the information about file modification date/time to be exposed in public. Just a sample case - the site owner delayed publishing some important document, but still want it to look just like it is published in time.

Description of solution

Just use some hash string instead of raw file last modifed date/time, something like this: http://mysite.com/myfile.pdf?ver=MjAxOC0wNC0yMC0x.

Affected version

• 9.3.2
• 9.3.1
• 9.2.2
• 9.2.1
• 9.2
• 9.1.1
• 9.1
• 9.0

[roman-yagodin]

This will require minor code modification of StandardFolderProvider.GetFileUrl() method and also correcting doc comment for PortalSettings.AddCachebusterToResourceUris(). Don't see any other references to it in the Platform code.

Possible implementations:

1. Use shortened timestamp string (w/o dashes):

public override string GetFileUrl(IFileInfo file)
{
...
    // Does site management want the cachebuster parameter?
    if (portalSettings.AddCachebusterToResourceUris)
    {
        return TestableGlobals.Instance.ResolveUrl(fullPath + "?ver="
            + UrlUtils.EncryptParameter(file.LastModificationTime.ToString("yyyyMMddHHmmssfff")));
    }
...
}

2. Use DateTime.GetHashCode():

Possibly shortest URL.

public override string GetFileUrl(IFileInfo file)
{
...
    // Does site management want the cachebuster parameter?
    if (portalSettings.AddCachebusterToResourceUris)
    {
        return TestableGlobals.Instance.ResolveUrl(fullPath + "?ver="
            + UrlUtils.EncryptParameter(file.LastModificationTime.GetHashCode().ToString()));
    }
...
}

3. Use DateTime.ToBinary() or DateTime.Ticks

Possibly faster to generate.

public override string GetFileUrl(IFileInfo file)
{
...
    // Does site management want the cachebuster parameter?
    if (portalSettings.AddCachebusterToResourceUris)
    {
        return TestableGlobals.Instance.ResolveUrl(fullPath + "?ver="
            + UrlUtils.EncryptParameter(file.LastModificationTime.ToBinary().ToString()));
    }
...
}

[sleupold]

sounds useful to me, unless the client would use the current date time to calculate cache time.

[mitchelsellers]

Given that this is a process to bust cache only, and not anything used for calculation we just need to be assured that it is different for all edits.

I'm a big fan of option 2 above, as that is the shortest URL and a simple change.

Feel free to submit a Pull Request for this.

[valadas]

I like the shortest url too.

[valadas]

Assigning this to 10 but if you want it in 9.4.1 and can submit a PR, that would be fine too I thing, that would not be any breaking change I assume?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[roman-yagodin]

Please don't close!

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

Is anyone planning to provide a PR?

[roman-yagodin]

It would be me. Please don't close.