API Changes #123
Comments
|
How does this affect the PRs that @Laurentww has submitted recently? |
|
I've only looked at the rate limit one. Only the image one seems to hit the official API and that's restricted to the tracks endpoint which I don't think changed. Looks like it's mostly the /me/foo endpoints. |
|
Adding images (#121) still uses the official API, as the standard app client id doesn't return rate errors here. Though, #121 could be improved as well by first attempting with the publicly obtained client id and reversing to the standard app client id on failure. As far as I can see, no pagination calls are made and the current API call uris are up to date. |
|
More api changes coming https://developers.soundcloud.com/blog/security-updates-api |
|
It seems the security related changes prevent mopidy-soundcloud from working now, as explained in https://stackoverflow.com/questions/68459401/soundcloud-api-authentication-always-throws-401-unauthorized |
|
looks like it. I am constantly getting |
|
According to soundcloud/api#151, this will not be fixed. Soundcloud api can now be used only together with a service that will issue a token. The tokens also need to be refreshed, since they are now time-limited. Can mopidy provide an API endpoint that the clients could use to fetch the tokens? Is there anything similar in mopidy already? |
|
Yes, Mopidy-Spotify works this way (utilising https://github.com/adamcik/oauthclientbridge hosted at auth.mopidy.com). We should be able to re-use that here also. Although I am not sure who controls Mopidy's soundcloud app and if they would need to update anything in the account settings, maybe it is @adamcik ? Although they (Soundcloud) maybe need to sort out their CORS issues also (from soundcloud/api#151). |
|
I don't think I have access to the oauth things for this account. However, I did play with using the bridge for SoundCloud and it worked at the time. So if we can recover the old account or get new credentials we should be good to go. Perhaps check with @tkem if he has access? But, ideally we should have this attached to a non-personal account like we've done for Spotify if at all possible. |
|
@adamcik Well, sorry, no access. |
|
The current |
|
As far as I know there's still no way to get new soundcloud credentials (facepalm) but if the authorization flow worked previously as is, maybe we don't need to hunt down the owner (although it'd be nice to sort that too). |
|
That was with the old flow that got / is getting removed, so won't work :( Checked https://soundcloud.com/you/apps and I don't have anything setup myself. |
|
That should be workable with the id + secret |
|
Thanks @kingosticks for getting the secret to me, I tried running this in my local test instance of the oauth bridge and I need to do one minor code change and it should all just work. Only ugly bit we'll have to do is to update https://mopidy.com/soundcloud_callback with some JS and a fallback link that sends people to https://auth.mopidy.com/soundcloud/callback with the same parameters and then we are back in business. So what we need to progress is:
What did I miss? |
|
And by should just work I mean that I did manage to get a working token in my locally modified test setup. |
|
is there a way where users can setup their own bridge in order to get soundcloud running again? |
|
Sorry for the delay, I haven't had much chance to work on my part of this. @chris-aeviator no not really, my code is on github, but you need credentials from soundcloud that they've stopped handing out years ago :( |
|
Ok - thanks for clarification - I can see that I can't register a new API account...bummer that soundcloud forces us to use their crappy player |
|
https://auth.mopidy.com/soundcloud is now up and running - since we can't change the redirect it sends us to https://mopidy.com/soundcloud_callback/?code=REDACTED&state=REDACTED and not https://auth.mopidy.com/soundcloud/callback as it's supposed to. I.e. next step is to add JS to With the bridge up and running none of the remaining work should be blocked on me, other than the one minor code change to the bridge that I only have in my dev setup. If we need to specify a default scope just let me know, and I'll update the config. But at least other contributors can pickup the other items I mentioned further up. |
|
The old case sends you to https://mopidy.com/soundcloud_callback/?code=REDACTED&state=REDACTED#access_token=REDACTED&scope=non-expiring and fails with eg https://mopidy.com/soundcloud_callback/?error_code=access_denied&error_description=user%20cancelled%20request&state=REDACTED So for successful requests we can check if the hash is set and decide if we should redirect or not, but for errors I think our only option is to encode something in our state parameter :/ |
|
Testing with changing the button href in https://mopidy.com/ext/soundcloud/ to point at the bridge and going through ends up failing with So perhaps we can just blindly assume that we should redirect this case to the bridge, and worst case it also fails the state check and no harm done, and in most cases we end up with a page that can handle the old and new cases. |
|
EDIT: NO IT DID NOT MY BAD, SORRY :(
|
|
As soundcloud "...will no longer be processing API application requests at this time...": https://soundcloud.com/you/apps/new is there any chance/workaround to get the integration to work? @nimbling how did you authorize? thanks |
|
I didn't, please see my correction. I did just log in using that link here: https://developers.soundcloud.com/docs/api/explorer/open-api - but it did not help as much as I thought it did. |
because of mopidy/mopidy-soundcloud#123
|
Hello all, sorry if I ask stupid questions, I am new to GNU/Linux and I want to listen to soundcloud with mopidy. so, which token should I put into "auth_token"? and did I understand correctly that this is the right way to install mopidy-soundcloud now: offtopic question: how do I turn off mopidy.service and use mopidy as user? do I just |
|
In order to obtain authenticate key go to https://mopidy.com/ext/soundcloud/ and utilize
Yeap, it worked for me two days ago. (I am afraid new realese still not yet ready. :( )
Yes, but as a root |
Mopidy-Soundcloud is broken: mopidy/mopidy-soundcloud#123
Mopidy-Soundcloud is broken: mopidy/mopidy-soundcloud#123
Mopidy-Soundcloud is broken: mopidy/mopidy-soundcloud#123
|
Jesus Christ, seems like I got it working now 💀 For those who haven't figured that shit out yet:don't use mopidy-soundcloud from AUR, Use this:
thank you @dominikdeka @kingosticks and all contributors of mopidy-soundcloud |
|
So... I never made that release?! Yikes. Sorry |
|
There is no need to run pip as root via sudo. The installation only needs to be accessible to the user running mopidy. I used |
|
I don't know what to do about this extension going forward. I can do this long overdue release tonight (I hope) but it's still fundamentally crippled by their incredibly stupid rate limiting. They (Soundcloud) keep banging on about how they are working away on the API but they re-iterated just last week they've no plans to open it up again. I don't get the point. |
|
A new release would be nice, thanks in advance. |
|
Thank you very much! Do you know if it will appear automatically in the apt repos at apt.mopidy.com? Here I see only 3.0.1: https://apt.mopidy.com/pool/ |
|
No, it's not automatic. It's a manual extra step, will request for it to happen. Should be in PyPI already though.
…On Sat, 18 Feb 2023, at 6:13 PM, herrernst wrote:
Thank you very much! Do you know if it will appear automatically in the apt repos at apt.mopidy.com? Here I see only 3.0.1: https://apt.mopidy.com/pool/
—
Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHEHKFMNMAUV7UZO2EQIETWYEGNXANCNFSM42OXY3AQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Thank you @kingosticks for preparing this release! |
|
Is anything broken again with this integration? It worked for a few days but it's failing again now, no matter the track I'm trying to play. I have tried both the latest pip version and the git version just in case. I can log in to SC with my token, browse my music collections and all, but whenever I try to play a track I get this: That Before I start diving into this can of worms, has anybody been experiencing the same issue? |
|
Working for me. Where is the output from https://github.com/mopidy/mopidy-soundcloud/blob/master/mopidy_soundcloud/soundcloud.py#L245 in your debug log? |
|
@kingosticks it is there, I just omitted it in the previous message. A full log trace for a request to play a SoundCloud track looks like this: This line is quite interesting: This is received just before the track fails to play. Is there maybe some weird redirect to cookielaw.org that prevents all the data from being retrieved? |
|
I think that's a normal (or at least functioning) part of the public stream client code. I get: But I agree it looks fishy. |
|
Hmm I think I know why. Your log traces look the same as mine for the first part, but I don't get beyond the And that's most likely because I use PiHole on my network, which redirects all the requests to that domain to localhost (I just don't like being harassed by cookie banners). So it seems like the original request to SoundCloud at some point triggers a request to cookielaw.org, which fails, and therefore the whole parsing logic fails. First of all, it'd be interesting to know why a backend request gets a redirect to cookielaw.org - as my voice assistant would say, "I can't show you a banner, I don't have a screen!". Secondly, maybe it's worth skipping those connections on the extension's side as well, if at some point we get that redirect? A workaround for now can be to whitelist EDIT I've done a quick test by whitelisting the domain on my DNS and things are working now - so that was indeed the issue. |
|
I was just going to ask if you have an ad blocker! The "public stream client" code scrapes Soundcloud's regular web page using Beautiful Soup, that'll be following all the But what I don't understand yet is, why doesn't it fall back to the (long-suffering rate limited) API method in this case? EDIT: Requests grabs the data, BS just parses it. |
That's a good question - I guess the fallback logic isn't really working as expected in this case. So from what I understand BS parses the web page, it extracts all the If that's the case, would it maybe make sense to check if Alternatively, if we get onto that domain through a redirect, maybe calling |
|
Maybe, but only until they change cdn.cookielaw.org to cdn1.cookielaw.org. And what if there was some external JS that was required (maybe updating the page contents to provide the data we are trying to extract)? I'm not saying these are not good ideas, I am just pointing out it's all a bit brittle. I think the first thing would be to make the fallback more reliable. In your case, I assume it gets an empty |
It's more like a |
|
Ahh ok so it's trying to update the public client_id that's needed when making requests to https://api-v2.soundcloud.com/foo for foo streams it just scraped from the public page (i.e,. not from API calls). In my case it finds the client_id in mopidy-soundcloud/mopidy_soundcloud/soundcloud.py Lines 238 to 241 in c61060a
|
|
So, We should |
|
I completely agree on (at the very least) log the exception instead of silently swallowing it - that would have definitely saved me some debugging time. It sounds to me like some of the JS is actually required, so my initial idea of just skipping Skipping If the extension only needs to scrape the page's static JS because it needs a particular one (the |
|
We could only download scripts from sndcdn.com (there are a bunch), but again, that domain could change and then it would be broken. Unfortunately, other than this cookie one, the scripts mostly look the same and if we decide on some arbitrary criteria that works today it could easily be wrong tomorrow. I think as long as we handle (and log) errored requests we'll be in much better shape. I'll hack a fix in and make an issue to fix it properly. Anyone else that hits this is very welcome to take it on. |
This workaround (fix?) was reported in mopidy#123
|
Search is working for me, but playing tracks are not... Running these versions (I think they are the latest): Log: UPD:
Thanks |
Soundcloud devs seem to be alive! They've made / are making some API changes which look like they will impact us. The API docs have moved here. The old endpoints still seem to work as of now. They also seem to be doing something to pagination and it sounds like the default response format is going to change.
The text was updated successfully, but these errors were encountered: