SoundCloud API - "same song" limitations? / 403 issue?

0
votes

I just updated an old web page of mine (originally created in 2014) that uses the SoundCloud API to play some background music directly from SoundCloud (see https://www.wothke.ch/ablaze/#/wright-and-bastard/venera). I have a SoundCloud client_id for the respective API - and my implementation had worked fine in the past: By default the page always uses the same song - though the user can add a respective permalink to the URL to play a specific SoundCloud song or playlist.

While migrating/testing my old page to WEBGL2 & ECMAScript 2015 I obvisously reloaded my respective page repeatedly and I noticed the following annoying effect:

At first the page plays the default song without any problem but after some page reloads (I would guess less than 10) SoundCloud seems to suddenly switch to "403 forbidden" errors.. if a different song is then specifically selected via the URL, then that song at first again plays fine, but after some reloads responses for that song then also suddenly switch to "403 forbidden". It seems that even a day later the "blocked" songs stay in the "forbidden" state.

It looks as if SoundCloud "now" might be using some kind of limit regarding the maximum number of times that one client (client_id) can load the same song within a given time interval. (For a page that uses the same technical client_id for all its visitors a respective limitation might be quite crippling.)

Any ideas (is there such a limit and what is it exactely)?

1
soundcloud

1 Answers

1
votes

Seems to be a f%&!&# caching issue.. SoundCloud redirects the stream URLs (e.g. https://api.soundcloud.com/tracks/511301766/stream?client_id=[my app ID]) to some Amazon server where the file is actually hosted (e.g. https://cf-media.sndcdn.com/AT5qm8ZFmiM0.128.mp3?Policy=[some id]&Signature=[some sig]&Key-Pair-Id=[some id]).

The respective "Amazon" URL seems to come with some kind of expiry date in the form of the "Signature" parameter. For some reason my CURL based PHP script kept picking up an old expired version of the forwarding URL (i.e. the first "stream" response must have been cached and therefore each new URL would work for a while until it expired..). I fixed the issue by dynamically adding a dummy timestamp param to the "stream URLs".