Fix non-admin users not being able to create playlists #524
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Found this while working on a tentative implementation for #522. It seems that #499 introduced some logic that prepopulates
playlist.UserID
to1
if nothing else can be decoded from the path.Before this PR,
ServeCreateOrUpdatePlaylist
was trying to figure out if a playlist existed by trying to open the file derived from its name. If the name does not exist,playlistIDDecode
returns an empty string, whichplaylistStore.Read
gladly accepts and proceeds to open""
, which implies.
, which does not fail. Then, the code added in #499 will slap the admin user ID on the playlist object, shortly beforeplaylistStore.Read
realizes this is actually a directory and returns an error.That error, however, was never checked. As a result, an empty non-existing playlist with
UserID: 1
was returned, and prevented creating playlists as every non-existing playlist will "belong" to admin, and thus no one other than admin could "modify" it.This PR adds a couple safety checks so this does not happen:
Open
Open
to fail earlier if a path to a directory is passed