You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A single-fix patch release: editing a chore that had a picture failed to save.
If you added an image to a chore and then tried to change anything about it — its name, points, days, anything — the save was rejected and the edit lost. Upgrading is all that is needed; your existing chores and their images are untouched and do not need re-uploading.
Fixes
Editing a chore with an image failed with image_url must be a TaskMate image URL
Error handling message: image_url must be a TaskMate image URL for dictionary
value @ data['image_url']. Got '/api/taskmate/image/<name>.jpg?authSig=eyJhbGciOi…'
(invalid_format)
TaskMate signs chore image URLs before handing them to the panel, because a browser does not attach the Home Assistant bearer token to a plain <img> request — an unsigned URL would 401 and the picture would never render. The chore editor seeds its dialog straight from that state and posted the signed value back when you hit save, but the save-side validator only accepted the bare /api/taskmate/image/<name>.jpg form and rejected anything carrying the ?authSig=… signature.
That is why uploading a new image worked while every later edit of that chore failed: the upload response is unsigned, the state is not. From the outside it looked as though adding a picture made the chore permanently uneditable.
The signature is now stripped and the bare path validated at the websocket boundary, so only the canonical URL is ever stored. That matters beyond the error message — a signature expires after 24 hours and is tied to one user, so persisting one would have rotted the stored chore and broken the delete-by-equality check that removes an image file when its chore is deleted or its picture replaced. The strict URL check itself is unchanged, so no traversal or foreign-URL surface widens, and the panel still renders the signed URL, so the editor preview keeps loading.
Reproduced on a test Home Assistant instance against the unpatched code, then confirmed fixed there: re-saving a chore with an image succeeds, repeated saves do not stack up signatures, and the image still serves.
(#828, fixes #827) — thanks to @markmghali for the report, which included the full error and made this a five-minute diagnosis.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
🚀 New Release: v5.4.1
A single-fix patch release: editing a chore that had a picture failed to save.
If you added an image to a chore and then tried to change anything about it — its name, points, days, anything — the save was rejected and the edit lost. Upgrading is all that is needed; your existing chores and their images are untouched and do not need re-uploading.
Fixes
Editing a chore with an image failed with
image_url must be a TaskMate image URLTaskMate signs chore image URLs before handing them to the panel, because a browser does not attach the Home Assistant bearer token to a plain
<img>request — an unsigned URL would 401 and the picture would never render. The chore editor seeds its dialog straight from that state and posted the signed value back when you hit save, but the save-side validator only accepted the bare/api/taskmate/image/<name>.jpgform and rejected anything carrying the?authSig=…signature.That is why uploading a new image worked while every later edit of that chore failed: the upload response is unsigned, the state is not. From the outside it looked as though adding a picture made the chore permanently uneditable.
The signature is now stripped and the bare path validated at the websocket boundary, so only the canonical URL is ever stored. That matters beyond the error message — a signature expires after 24 hours and is tied to one user, so persisting one would have rotted the stored chore and broken the delete-by-equality check that removes an image file when its chore is deleted or its picture replaced. The strict URL check itself is unchanged, so no traversal or foreign-URL surface widens, and the panel still renders the signed URL, so the editor preview keeps loading.
Reproduced on a test Home Assistant instance against the unpatched code, then confirmed fixed there: re-saving a chore with an image succeeds, repeated saves do not stack up signatures, and the image still serves.
(#828, fixes #827) — thanks to @markmghali for the report, which included the full error and made this a five-minute diagnosis.
Upgrading
HACS → TaskMate → Redownload → pick
5.4.1→ restart Home Assistant.No configuration changes, no card changes, no migration. If you have a chore whose edits were failing, it will simply save now.
Full changelog: v5.4.0...v5.4.1
Upgrading
Update via HACS or by downloading the latest release and copying to
/config/custom_components/taskmate/.After updating, restart Home Assistant. Lovelace resources will update automatically on restart.
💬 Questions or issues with this release? Reply below or open an issue.
All reactions