Collections API returning incorrect data

MusicBrainz Development
, ,
1

For the last two days I’ve noticed the collections API seems to be returning incorrect data.

Here’s an example script:

import pprint
import musicbrainzngs

musicbrainzngs.auth('waxie', 'xxx')
musicbrainzngs.set_useragent('myapp', '1.2.3')
cs = musicbrainzngs.get_collections()
pprint.pprint(cs)

And here’s the output (with potentially sensitive data redacted):

{'collection-count': 1,
 'collection-list': [{'editor': 'USERNAME',
                      'entity-type': 'release',
                      'id': 'COLLECTION ID',
                      'name': COLLECTION NAME',
                      'release-count': 3974,
                      'release-list': [],
                      'type': 'Owned music'}]}

The response is incorrect - this collection list is for a user other than the one I authenticated with.

The response itself appears to be cached for an indeterminate amount of time. Yesterday I was given data for yet another user.

Has anyone else experienced this?

3 Likes
2

This has been reported at https://tickets.metabrainz.org/browse/MBS-10169, as the result of some recent changes to the musicbrainz website. This also affects Picard. The musicbrainz developers will try and fix it as soon as possible, thanks for the report.

2 Likes
3

Funny… I was just dropping in to say the same about Picard.

I’ve got someone else’s collection appearing in my list - “SonicMix”

And it is a bit hit and miss if I see any of my own collections appear. Currently I have 1 of 4 listed.

1 Like
4

Hi, @zas just updated some caching options that changed two days ago. That may have fixed it, but this bug cannot be reproduced easily. Please report if this bug occur again here, thank you.

1 Like
5

Hello @yvanzo - Thanks a Lot. :+1:

That has certainly changed Picard for me. Back to solid and reliable list of my four collections.

This had been easy to repeat for me. Each time I restarted Picard I would have a different set of collections listed. Usually one or more of mine, but at least once I got a different one selected.

Now every time Picard is back to 100% reliable only my four collections.

But that means I missed out on the chance of adding random stuff to SonicMix… could have been an interesting surprise for someone. LOLs

6

Sadly for you, that wouldn’t have worked anyway! (well, I really hope so, in any case! :smiley: ) . But hey, if what you want is to add stuff to other people’s collections, then you’ll like MBS-9428 which is almost ready. You’ll just need to get their permission first (booooring).

3 Likes
7

Yeah - that would have been a bit too much of an unexpected feature. :smiley:

The idea of Shared Collections is certainly an interesting sounding idea. I can see a few potential uses for that kind of thing.

8

@IvanDobsky: Thank you for confirming this bug is now fixed.

Note: Only public collections of other users could be seen, not private ones. It only affected the retrieval of collection list, it did not allow editing collections of any other user.

To sum up, no user private data leak, no privilege escalation, still good chances to not retrieve the correct collection list.

1 Like
9

That may not be totally true, at least in my case.

When I first noticed this problem, the response from the API included a collection from a user who has no public collections. Granted, it didn’t show the releases in that collection but it did reveal that they had at least one private collection, along with its name, collection type and release count.

2 Likes
10

Thank you for sharing this, it leaked private data after all, fortunately limited to collection list.

1 Like
11

Just a quick note to add - thank you for being so quick on to this issue and fix. Normally when I see mention of a ticket it means a fix at an unknown future time. This quick response was very good to see.:+1:

1 Like