-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make custom wallpapers expire earlier / daily #700
Comments
I've been thinking about this lately. I think the best way would be to generate a unique URL for the wallpaper (sha256.jpg) and include that in the settings returned to the client before authentication. That way the cache time can still be high, but will break immediately when the user changes the wallpaper image (even if it's named the same thing). |
Would adding a redirect to that unique file-name from |
On startup or config save the UI will now check to see if a custom login wallpaper path has been set in the config.json or if a file named When the UI is loaded it calls the The cache time is still set to effectively never expire on these files, but by doing it this way, if the custom wallpaper is modified or added, the changes will be reflected immediately. https://github.com/oznu/homebridge-config-ui-x/wiki/How-To-Test-Upcoming-Changes |
Both the default (static) and custom login wallpapers currently never expire. I would argue while this makes sense for the default Wallpaper, the expiry for the custom login wallpaper should be lower, maybe around a day or even hours, and certainly not immutable: This allows to set a changing wallpaper (e.g. by separately downloading a daily image from one of the many different sites that provide that) to a fixed location and have HomeBridge Config UI X display it reliably.
https://github.com/oznu/homebridge-config-ui-x/blob/586cbd127c0c37b6bb7e3ef10f3b186a7a4d89fb/src/main.ts#L86-L99
So for example revalidate / download daily:
There are obviously other approaches, e.g. allowing for URL's in the setting, but these bring additional troubles with Content Policy, offline access and more. So I think reducing the cache time for custom wallpapers is a pragmatic tradeoff for most use cases.
The text was updated successfully, but these errors were encountered: