12-16-2020, 06:39 PM
(12-16-2020, 11:53 AM)Mark Dirac Wrote:(12-05-2020, 04:37 PM)Mark Dirac Wrote:(12-04-2020, 04:45 PM)SoundAdikt Wrote: It's no longer supported due to Qobuz requiring a unique and private app ID and secret ID
For the record, and to minimise fake news, Qobuz is streaming very well directly to Moode on my Allo USBridge controlled by BubbleUPnP, as suggested by SoundAdikt. The stream does not pass though my tablet.
(Bubble UPnP authenticates my Qobuz password, and validates Moode's (actually, UpMPDcli's) request to draw the stream from Qobuz.)
True, but to maximize real news, Qobuz, like Tidal before it, has been making it more and more difficult for FOSS developers to keep their plugins working.
Here's a year-old news item from the upmpdcli website
Quote:2019-10-06Qobuz access was revoked: If you were using Qobuz and it's not working any more, don't pull your hair, the Qobuz plugin stopped working (either through the Media Server or with OHCredentials). Qobuz revoked the app_id, and also deleted the API documentation on Github. If you are a hardware integrator/manufacturer using upmpdcli to support Qobuz access (I know there are some), I made a modification to the Qobuz plugin so that the app_id/secret can be stored externally instead of being embedded in the source. This means that, if you can convince Qobuz to supply you with the appropriate pair, you can easily restore function, without having to support a modified module. Of course, this supposes that the API itself does not change.
More recently, a clever hack from another developer restored the Qobuz plugin functionality
Quote:2020-12-08Version 1.5.5. Fix initial issues in 1.5.2. See the release notes. Note: Tidal access does not work any more at all. Qobuz access works through the media server, not through the Kazoo or Lumin login (OpenHome Credentials).
Essentially, the upmpdcli media server Qobuz plugin tells the Qobuz servers it is the Qobuz web client.
That's working for now, but my guess is it won't work forever.
Most if not all the music streaming services have moved to oauth2.0 authentication service. One now needs three things to stream from their service:
- A stable API to write code against. If one is lucky this API is published. As seen above, Qobuz deleted their documentation so hackers had to reverse-engineer the API by packet-sniffing while running official Qobuz apps. The streaming service can change its API without notice.
- Authentication of the client app. This means the developer registers the app (upmpdcli and its Qobuz plugin in our case) with the service and receives an app ID and app "secret". FOSS developers haven't been able to register their apps so they play "button, button, who's got the button", again through packet sniffing. This is where games like masquerading as the web client come into play. When the streaming service gets annoyed, it invalidates the particular ID/secret pair in their authentication server. As far as I know, no FOSS developer has ever received a "cease and desist" letter from a service's lawyer, but it could yet happen.
- Authorization by the user for the registered client app to access the service. Here's where one signs into the app with account username/password. By its very nature, this should always work if the user credentials are legit.
Kent