Append version string to resources to enforce reload after updating #2367
Comments
Kimmax
changed the title
|
After much pondering and reports of aggressive browser caching: the plan is to embed the git commit hash into file firmware-product and use this as a version string which is unique and allows us to magically weave this change into the build process. |
Part one makes it possible to inject branding info from the Makefile which is not fully complete yet but can always be finished. The new hash value can thus be used as a unqiue identifier for page resources that may be subject to caching. By using the git hash it allows us to have this effect on test commits as well as earch working version as we don't want to track the changes for each file but still get a good amount of caching.
|
It's funny, because this has potential for a CVE especially if done on the login page as well as it is a version disclosure. So we'll skip the login page and try to discuss this further internally before shipping it. :) |
|
@fichtner If you want to do that, the /ui pages need it as well. |
|
no, this is only for resources |
|
have not seen it - it is already done: https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/views/layouts/default.volt |
|
We could generate a token after an update to avoid version leakage, the @fabianfrz this code seems to break ui_devtools at the moment, which looks like your other issue. |
|
I thought commit hash as its more practical than generating a version tag for machine operations, but in any case that inclusion process is settled for both "make install" (and "make upgrade" and all the package building) and could push an arbitrary string into it while doing the operation. The git hash avoids collisions, but the fact remains that the build-time string is not random after shipping it in a release and doing some pseudo-random runtime thingy seems over the top for the problem at hand. |
|
@fichtner stat can be used: md5(file creation time) |
|
That's still static on build time and you can identify the version from it... |
|
@fichtner no, it is dynamic (depends on install time). A single nanosecond would give another hash |
|
But then we'd have to write firmware-upgrade or some other arbitrary file or possibly the config.xml which I wanted to avoid in the first place because firmware-upgrade already offers data without overhead. |
|
no, just call stat on the file which is linked. opnsense/plugins% echo '<?php $file = "LICENSE"; echo $file . "?" . md5(stat($file)["mtime"]) ?>' | php
LICENSE?eba2cb72eed8a4689ebc202bca9d5146 |
|
Ok, this seems ready for general release 4178038 from my side in 18.7.4 after a final testing round in 18.7.3. Some plugins need to be adjusted later though... |
TL;DR:
Add
v=<Version>to script and style resources to force reload them after updating opnsense, while keeping the caching functionality of browsers intact.I ran into cache problems after a script was updated and my browser refused to load the new one. While this is not a big problem, it's a known one that can be easily mitigated by appending a
v=<Version>string to the URL's of said resources. While browsers still cache them, changing the version number, e.g. after an update, forces the browser to treat the resource as a new one, which is guaranteed to be loaded from the server.The text was updated successfully, but these errors were encountered: