JS SDK compliance with new API requirements

[alexweinstein]

Thank you again for all the work you are doing for this community. I fully support this effort to make the API more secure and robust.

My app is built mainly on the official JS SDK. I am trying desperately to update to keep it current, but am confused as to which documentation is up to date and which is not. For example, in many threads you advise us to follow the authorization flows as documented here. But on that same page are guidelines for Client-side JavaScript Applications, which is not currently supported according to the official repo.

Can you shed some light on which documentation on developers.soundcloud.com is officially supported? Or do you have any advice or direction for those of us that use the JS SDK?

I can get into the specifics of my app, but thought I would start more generally as it might help others in similar situations.

Thanks again.

[dasha-kobzeva]

Hi @alexweinstein ,
thank you for opening this issue. I understand that our documentation might create confusion at this point. Unfortunately, we haven't had a chance to update it just yet.

I believe the guidelines for Client-side JavaScript Applications can be disregarded as we do not provide a pure client-side integration at the moment.

With new security updates, we only support server-side as the authorization has to have a server. JS SDK was recently deprecated and not compliant with new changes.

We would recommend building a custom integration based on our API spec.
Let me know if it answers your questions.

Best,

[pluc]

I see that you are now deleting comments critical of your botched migration from paying customers. This is unacceptable, plain and simple. You are breaking your own features, your own backward compatibility, your own SDKs and every third party library that exists, and your answer is "yeah we didn't have the chance to update our documentation". How are paying customers supposed to even keep their service unaffected when the libraries, SDKs and documentation have all taken a back seat to whatever it is you're doing now?

Seriously, Soundcloud you need to get your shit together and make this right.

[dasha-kobzeva]

I see that you are now deleting comments critical of your botched migration from paying customers. This is unacceptable, plain and simple. You are breaking your own features, your own backward compatibility, your own SDKs and every third party library that exists, and your answer is "yeah we didn't have the chance to update our documentation". How are paying customers supposed to even keep their service unaffected when the libraries, SDKs and documentation have all taken a back seat to whatever it is you're doing now?

Seriously, Soundcloud you need to get your shit together and make this right.

Dear @pluc,

I understand you are not agreeing with recent changes.
Yet leaving irreverent comments in every issue is not gonna achieve anything. You are only showing your bad manners.
Please respect your fellow users and the Soundcloud team.
If you continue like this, we will be forced to ban you.

We are sorry to lose you as our customer, but if you are incapable of updating your application, this is a tradeoff we are willing to make.

Thank you

[alexweinstein]

Thanks @dasha-kobzeva.

If we can develop a server-side flow to get the authentication, will the remaining functions of the js sdk still work if we pass the access_token? ie .initialize(), .play(), .post() etc.

Again, just trying to get an understanding of what SoundCloud is supporting, because it's not very clear at the moment.

[pluc]

I am perfectly capable of updating my application, however I have to deal with official SDKs that are no longer supported, third-party libraries that are broken because of your changes, documentation that is no longer accurate, and support that is dismissive of client issues. You are making this so much harder than it should be, because you haven't bothered to update your documentation, have clear error messages or have support staff to deal with the influx of new requests based on the changes that you are imposing to your users.

@alexweinstein The JS SDK doesn't work at all, period, and you will not get answers about it here:

<script src="https://connect.soundcloud.com/sdk/sdk-3.3.2.js"></script>
    <script>
        SC.initialize({.....});
    </script>

Uncaught ReferenceError: SC is not defined

[mgoodfellow]

@alexweinstein the issue here is you really don't want to be leaking your access_token to the client side - I think you are better of proxying the calls via a thin server that appends a stored access_token

[mgoodfellow]

@pluc your code sample works fine:

Maybe use dev tools to see why your browser fails to load the script? 😂

[mgoodfellow]

@pluc I know you are on some rampage because you are upset, but quite frankly you are going the wrong way about it. I get that you are frustrated, but a word of friendly advice - the approach you are taking here and on other issues isn't a good way to get help from people.

The (small) team at SoundCloud have been taking a fair bit of flak on this repository, but I have found that approaching them (or the community - (hello! 👋 )) with as much information as possible to describe the use case and the issues you are having, that they have been very helpful in resolving the issues or helping out as much as they can. Generally a little bit of respect and patience goes a long way - this is true for most things in life. Considering the history of the SoundCloud API and the lack of a developer community, it's great to see that they are investing time and effort on improving it.

[pluc]

@mgoodfellow I find it offensive that I am asked to do my due diligence before asking anything when Soundcloud themselves are rounding corners. It's embarrassing for a company with the stature of Soundcloud to half-ass the implementation of security features and leave their clients to figure out how to be compatible when their own documentation is outdated. I've been at this for a week and I've gone through multiple answers for how my stuff doesn't work, from "your api key was secretly deactivated" to "you need to create a new app even though we don't allow you to" and even "we fixed a bug in our backend try now". It's retarded.

[alexweinstein]

Thank you @mgoodfellow. I will look into your advice about the server-side access_token.

The official JS SDK gave us a simple tool to build powerful applications. But if I'm understanding correctly, it seems that it was crazy insecure. So SoundCloud is dialing it back, starting over and releasing only the API. Telling us to either build our own SDK or wait for the community to do it. Essentially raising the bar for who gets to build on the platform.

Is this correct?

Again, I understand why they're doing this. But my concern is that the plug is being pulled too soon and years of work is being thrown away before we are ready.

[mgoodfellow]

@alexweinstein It's hard to know exactly what you are using from the SDK, or if you are just using server side (client_credentials stuff), or if you need user context.

But greggman wrote a small nodejs server (https://github.com/greggman/soundcloud-audio-reactive-example) that proxies requests via a server and adds a server token - maybe this will help?

In my use case, we never have the client call the SC API, instead everything happens via a server layer which allows us to control issuing/refreshing etc of tokens, and deals with server scoped, or user scoped tokens accordingly. It is my understanding that going forward you will really need a server side component.

[dasha-kobzeva]

Thanks @dasha-kobzeva.

If we can develop a server-side flow to get the authentication, will the remaining functions of the js sdk still work if we pass the access_token? ie .initialize(), .play(), .post() etc.

Again, just trying to get an understanding of what SoundCloud is supporting, because it's not very clear at the moment.

With the current implementation, JS SDK won't work, as you need to pass the token in the header and it is not implemented.

We are looking for maintainers for JS SDK if you are interested.

To summarise:
I think if you can build a small server for auth, you can also call our API from it and handle the responses in the browser. What @mgoodfellow suggests is a good approach.

Cannot promise, but maybe in the future, there will be a way for pure client-side integrations.

We will try to update the documentation in the following week. We are short-handed at the moment, as some folks are on holiday.

[dasha-kobzeva]

Thank you @mgoodfellow. I will look into your advice about the server-side access_token.

The official JS SDK gave us a really simple tool to build really powerful applications. But if I'm understanding correctly, it seems that it was crazy insecure. So SoundCloud is dialing it back, starting over and releasing only the API. Telling us to either build our own SDK or wait for the community to do it. Essentially raising the bar for who gets to build on the platform.

Is this correct?

Again, I understand why they're doing this. But my concern is that the plug is being pulled too soon and years of work is being thrown away before we are ready.

You are correct. From now own Soundcloud is only maintaining the REST API, and SDK support is deprecated. I agree it was a rather quick and aggressive change, but to improve the API, allow new apps registration, and better service we had to make these sacrifices.

It is not ideal, and we are trying to be as less disruptive as possible, but the abuse of our platform got out of hand.
I hope you understand.

[mgoodfellow]

@alexweinstein I think this was touched upon here: #114 (comment)

But summary is:

• All SoundCloud API calls should be moved to the a server application
• Server would do all the communication with SoundCloud
• Client on every request related to SoundCloud API would call the server application to do the request on its behalf

This would make a client-side SDK very implementation specific with your own stack, so I imagine going forward there will only be server side SDKs (C#, PHP etc).

If the JS SDK was maintained it would need to become a nodejs SDK for JS to be imported into a server-side nodejs app IMO.