[JS] Force update js-file in browser after upgrade luci-app-ANY

remittor · October 26, 2024, 5:52pm

Problem

After updating the JS-part of any package, the user is forced to clear the browser cache.

Proposed Solution

Add the version of the ipk-package to which the file belongs to the JS-file name.
Instead, all JS-files are now appended with a common version of LuCI.

github.com

openwrt/luci/blob/392b7e6b0d56d7d292b7f662b0728620397613e9/modules/luci-base/htdocs/luci-static/resources/luci.js#L2229-L2237


      
          			document.querySelectorAll('script[src*="/luci.js"]').forEach(function(s) {
          				if (setenv.base_url == null || setenv.base_url == '') {
          					var m = (s.getAttribute('src') || '').match(/^(.*)\/luci\.js(?:\?v=([^?]+))?$/);
          					if (m) {
          						setenv.base_url = m[1];
          						setenv.resource_version = m[2];
          					}
          				}
          			});

github.com

openwrt/luci/blob/392b7e6b0d56d7d292b7f662b0728620397613e9/modules/luci-base/htdocs/luci-static/resources/luci.js#L2446


      
          			if (classes[name] != null) {
          				/* Circular dependency */
          				if (from.indexOf(name) != -1)
          					LuCI.prototype.raise('DependencyError',
          						'Circular dependency: class "%s" depends on "%s"',
          						name, from.join('" which depends on "'));
          
          				return Promise.resolve(classes[name]);
          			}
          
          			url = '%s/%s.js%s'.format(env.base_url, name.replace(/\./g, '/'), (env.resource_version ? '?v=' + env.resource_version : ''));
          			from = [ name ].concat(from);
          
          			var compileClass = function(res) {
          				if (!res.ok)
          					LuCI.prototype.raise('NetworkError',
          						'HTTP error %d while loading class file "%s"', res.status, url);
          
          				var source = res.text(),
          				    requirematch = /^require[ \t]+(\S+)(?:[ \t]+as[ \t]+([a-zA-Z_]\S*))?$/,
          				    strictmatch = /^use[ \t]+strict$/,

All files in the package are known. The version is also known:

root@OpenWrt:# opkg files luci-app-zapret
Package luci-app-zapret (66-20241025) is installed on root and has the following files:
/www/luci-static/resources/view/zapret/service.js
/www/luci-static/resources/view/zapret/settings.js
/usr/share/rpcd/acl.d/luci-app-zapret.json
/www/luci-static/resources/view/zapret/tools.js
/usr/share/luci/menu.d/luci-app-zapret.json

root@OpenWrt:# opkg info luci-app-zapret
Package: luci-app-zapret
Version: 66-20241025
Depends: libc, zapret
Status: install user installed
Architecture: all
Installed-Time: 1729956777

remittor · October 27, 2024, 8:32am

I found a pretty similar problem on GitHub.
And they advised that the user should manually clear the cache in the browser.

@jow , can you comment on my problem that I described?

github.com/openwrt/luci

Type Error due to stale browser cache after LAN address change

opened 08:12PM - 17 Mar 22 UTC

closed 07:14PM - 26 Apr 22 UTC

louisheibert

Archer 1750 A7 OpenWrt 21.02.2 r16495-bf0c965af0 / LuCI openwrt 21.02 branch gi…t-22.052.50801-31a27f3 (with all available updates as of 3/16/2022) ## Steps to reproduce: 1. Install all recommended updates (in LuCI) after the initial bare firmware installation. 2. Change the LAN interface IP address in LuCI, uci, or network config file. 3. Restart network or reboot router 4. click on the "Network > Interface" or "Network > Firewall" menu option ## Actual behavior: 1. A red Type Error "firewall.getZoneColorStyle is not a function" appears 2. Network (or Firewall) screen never opens. ## Expected behavior: (it works instead of not working) ## Additional Information: Clearing the browser cache (at least in Firefox) fixes the problem. I'm not a web app expert by any means... however, I suspect web apps are supposed to poison cache data when necessary. Perhaps this is just a Firefox problem because nothing from the old ip address should be referenced in cache when using the new ip address. It should effectively be a completely different web site from the browser's perspective. In fact it really seems like a security bug on their part. Still, I thought you should know since I've never had this problem with OpenWRT before.