`saveStatusPage` socket handler does not use `icon` specified in payload if not base64-encoded
jmolnar-comparative opened this issue Β· comments
π I have found these related issues/pull requests
I did not find any related issues
π‘οΈ Security Policy
- I agree to have read this project Security Policy
Description
uptime-kuma/server/socket-handlers/status-page-socket-handler.js
Lines 139 to 157 in dbbc79a
config.icon
is never again referenced, only config.logo
π Reproduction steps
write to the status page socket handler with a payload like:
{
"icon": "/path/to/an/icon.svg"
}
or similar.
π Expected behavior
Status page should use provided icon.
π Actual Behavior
Status page keeps using whatever icon it is already using
π» Uptime-Kuma Version
1.23.13
π» Operating System and Arch
Debian bookworm aarch64
π Browser
Google Chrome 124.0.6367.119
π₯οΈ Deployment Environment
- Runtime: Docker 20.10.21 / nodejs 20
- Database: sqlite/embedded
- Filesystem used to store the database on: Debian/ext4 SSD
- number of monitors: 1
π Relevant log output
No response
Yes that is a bug.
Thanks for digging into the code. Would you like to provide a PR => be attributed with this fix?
I am wondering: How did you come across this?
I have a PR almost ready, I'm just currently confirming on my patched local that it's possible to use the URL variant at all.
Assuming I can work out some CORS issues, then I'm expecting I can provide a simple one-liner.
As to how I came across it: I am automating a from-scratch status page setup, so the UI-driven upload flow is a no-go for me. I also don't really like the base64 upload because then I have to pull the current image and check if the contents match since I want to report whether I am changing the icon. I'd rather use either a cross-origin URL or a path relative to the data volume (I'm using the docker deployment variant).
I don't care about the attribution though; this is not my personal account
Confirmed that things work fine if I do this simple fix: #4750