https://musicbrainz.org/ submissions via Picard break with containers

[mcepl]

Before submitting a bug report

• I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
• I searched for existing reports to see if it hasn't already been reported

Step to reproduce

1. Start Firefox (using the one from org.mozilla.Firefox Flatpak)
2. Set https://musicbrainz.org/ with a specific container (“Research” in my case)
3. Start Picard (again, a Flatpak from https://flathub.org/apps/org.musicbrainz.Picard)
4. Select a folder with large number of MP3s with rich metadata (purchased from the Czech Radio) and clusterize all tracks
5. Select “Submit cluster as a release …”

Actual behavior

https://tickets.metabrainz.org/browse/MBS-13046

Expected behavior

When I remove https://musicbrainz.org/ from any container, Picard works.

Additional informations

No response

Provide a copy of Troubleshooting Information page (optional)

No response

[phw]

There is a lot of discussion in the linked MetaBrainz ticket. But to sumarize here is our findings

The integration between the Picard desktop app and the MusicBrainz release submission form works by the desktop app serving a small HTML form via a local web server (by default on http://127.0.0.1:8000). The form submits data per POST to https://musicbrainz.org/release/add

Now if musicbrainz.org is configured to run in a container, but 127.0.0.1:8000 isn't, multi-account-containers seems to intercept this POST call and turn it into a normal GET http://127.0.0.1:8000 inside the container.

The actual issue is the change of request method, which leads to the submitted data being lost. This seems to be similar to issue #1736

Ideally multi-account-containers would intercept the full original POST request with all the submitted data and headers and perform the POST again inside the container. Needs some consideration if a user prompt is needed for security / privacy reasons. Maybe even with displaying the data again that is about to be submitted.

For now a solution for the user is to add http://127.0.0.1:8000 to the same container as used for musicbrainz.org

[dannycolin]

IMO, the ideal solution would be for the Picard app to use the MusicBrainz API directly instead of patching Multi-Account Containers to accommodate one specific application.

[phw]

For one this is not "patching Multi-Account Containers to accommodate one specific application". This:

POST https://example.com/

some data

is not the same as a GET https://example.com/. Those are not interchangeable, but Multi-Account Containers treats them as such. Hence I think this request is to properly handle POST calls as such. The MusicBrainz case is an example of this happening.

Second Picard is using the official way to seed the release editor. There is no other "use the MusicBrainz API" here.

It's also not only Picard. There are for example also tools to post to the same editor from other domains to import music data (e.g. from Bandcamp or Discogs). Then you get the same problem if those sites are not in the same environment the POST will be changed to a GET.