simple-freesound library broke because of redirection to secured urls

[joseph larralde]

Hello,

Recently I wrote this little library for nodejs and the browser : http://github.com/Ircam-RnD/simple-freesound.

All it does is to provide a simple query interface for the api. It gets a bunch of sound ids in response, then parses the hq mp3 preview urls in the detailed info returned by the api from each sound id, and downloads the hq preview files automatically (either via ajax in the browser or using http.get in node).

The idea is that it can either work as a simple browser library allowing to easily get some mp3 files to play from a few search terms, or on a local network where node will take care of downloading the files from the search terms and serving them to local clients so that they can jam together.

Yesterday I came back working on the project for which I wrote it, and noticed it didn't work anymore ...

I was about to come by here and complain "why my awesome library doesn't work anymore ?", but I noticed that I was simply redirected to secure versions of the urls.

So I just changed the urls I got from the detailed info returned by the API so that they are prefixed with "https", and switched from http.get to https.get in nodejs.

Now it's working again.

I have a couple of questions :

- is this approach sustainable ? or is it likely to break in a near future ?

- if it is sustainable (which means I'm not doing something "bad"), shouldn't the api return the https urls directly in the detailed info of the sounds ?

For the time being, I'll update my lib with these fixes and move forward with my project.

Thanks for any feedback,

Joseph

[Frederic Font]

Hi Joseph,

We recently introduced redirects to https and no-www to all requests to Freesound except for those to the API.

However, we also included the requests to the static content (like the previews) which should have not been included.

The idea is that at some point you should update your client to access the API via https and no-www, but that everything would still work as expected if you don’t do it.

Therefore it was our mistake that we did not exclude previews form the redirect. We are aware of the problem and will fix it soon. However I suggest you do the changes in your client and this will fix it immediately on your side.

In the future we might completely drop support for no-https in the API, but if this ever happens there will be an announced and long transition period.

Thanks for reporting,

frederic

---

Frederic Font

Music Technology Group

Universitat Pompeu Fabra

freder...@upf.edu

Freesound | www.freesound.org

Audio Commons | www.audiocommons.org

--

---
You received this message because you are subscribed to the Google Groups "Freesound API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freesound-ap...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[joseph larralde]

Hi Frederic

Thank you for your answer.

By "we'll fix it soon", do you mean that you will remove the redirects for the static contents, or that you will update the previews' urls returned by the API to https ?

For the moment I automatically set the protocol to "https" in the urls before I download the previews, but if you remove the redirects I will have to revert or not to my old code ...

Anyway, for now my library is back working but I'll know where to look if I run into new trouble :)

The only other thing I might have to updated someday then, is the API entry point which might change for https, but not in a near future if I understand correctly.

Cheers,

Joseph

[Frederic Font]

Hi Joseph,

We just removed the redirects for the previews so it should all work fine.

The URLs returned by the API follow the same protocol and scheme as used in the request, so they will be ok if you use https and no-www (well, now these will be ok anyway because we removed the redirects).

I recommend you anyway to update the library to https and no-www. It should really simply be a matter of changing the base url.

Cheers,

[joseph larralde]

Hi Frederic,

Thanks a lot !

I let the url conversion to https and I can confirm it still works.

By the way I finally made available an app online which uses freesound api.

It targets smartphones and still lacks some explanations, but it's here : https://como.ircam.fr/apps/freemix

I'll update como.ircam.fr soon to add some documentation (and more apps)

Cheers,

Joseph

[Bram de Jong]

Hi Joseph,

Perhaps it might be nice to out the name of the contributor on top of the waveform? The attribution would be a bit nicer that way...

Bram

To unsubscribe from this group and stop receiving emails from it, send an email to freesound-api+unsubscribe@googlegroups.com.

[joseph larralde]

Hi Bram

For the moment I'm mostly struggling with safari issues ...

Anyway, it's a smartphone app, so I prefer not to clutter the visual interface with too much information, and focus on what I suppose users will want to see in the first place : the sound name.

As you saw, there's an "info" button that displays the contributor and license, between other info.

I think this is fair enough, don't you ?

Best,

Joseph

To unsubscribe from this group and stop receiving emails from it, send an email to freesound-ap...@googlegroups.com.