The NXRM UI exposes various links a user can open in their web browser to directly download repository content ( components / assets ).
Currently no Cache related HTTP headers are set when the response is successful (200) downloading these files. Cache headers which tell the web browser to not cache the result are sent for 403 Forbidden responses.
After a successful download of content, the user permissions may have changed in the backend to DENY access to these files. Subsequent attempts to download the same file may appear to work, but don't actually contact the server.
Check the video diabolical-fake-download-of-cached-file.mp4 for how downloads can manifest when not actually contacting the NXRM backend.
The problem is this creates a bad UX:
- an appearance of privilege escalation when none actually exists because the new privileges were not actually checked
- the user may sign-out their NXRM session and then immediately sign back in and appear to download the same file despite not actually having the permissions to do so
- an appearance the server was contacted to download the file ( server is still available ) when it is not actually still available. ie. it is actually offline now )
If downloads are attempted from within the NXRM UI, NXRM should set cache headers such that a web browser (UI) should NEVER cache the download attempt and exhibit the confusing "fake download" behaviour.
Altering the cache related headers for any other user agent download is strictly not in scope.