New Api going live... with Jamendo App Award (?)

[Claudio Ortelli]

Hello everybody,

we are glad to announce that in few days we are going to release the NEW JAMENDO API!

You will find lot of new stuff: a good documentation, an oauth server, many new methods and data. More details on that just after the official release...

We discussed internally about a JAMENDO APPS CONTEST. Developers would be able to participate with any kind of application using the new api. The proposed contest duration is about 2/3 months. Every team may become the winner of the Community Award (community voting) or the Jamendo Team Award (our team voting). We think about at least $1000 for each prize, but we may increase and/or add new prizes. Community will be completely free to vote, while Jamendo will reward the most innovative application.

Before proposing the full rules and going official with the contest we would like to measure your interest in such initiative. Only a good response from you can motivate us to start the contest... Would you guys be interested to participate? Which kind of application would you like to develop? Give us your opinions!

[Ae]

Sure, I would be interested. I already have an app though, would updating for the new API count as a submission?

Joel

Sent from my iPhone

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

[Cássio]

What a great news!

I'm anxious to test these news functionalites...

Cheers,

Cássio

[Mario Boikov]

Sounds good (assume that you still allow 'anonymous' API calls for the majority of the functionality)! 

I'm in

/Mario

[samuel baudouin]

I'd be interested, although it would depend on the rules themselves as
well as what kind of apps we are talking about ?
For which kind of plateform? Programming Language?

But overall I think it would be great just to see new ideas coming
out, and of course the promotion of Jamendo, in general!

--
Sam

[Claudio Ortelli]

Good start :-)

I answer all together to the incoming questions:

I'd be interested, although it would depend on the rules themselves as well as what kind of apps we are talking about ? For which kind of plateform? Programming Language?

We are really open to define the rules all together. At the moment, our idea is to open the contest to any kind of app: desktop software or plugin, browser plugin or site, mobile app,.. any! Same concept for programming language.
We don't want to put any pre-filter, and just let your ideas come out freely, as well as let the community freely vote. As mentioned, for the Jamendo Team Award, we'd focus on the innovation character of each app.

assume that you still allow 'anonymous' API calls for the majority of the functionality

For understandable reason (I believe so...), the new api requires a client_id, which you can freely and easily obtain. Please, don't really see this as a barrier, because it isn't so!

I already have an app though, would updating for the new API count as a submission?

Yes! Our approach is this: more or less we already know the existing applications. Take for instance Jammap. That's a nice one. A simple upgrade to new api would let it be able to participate. It could easily win the Community Award, but we wouldn't consider it 'very innovative', as it's just an upgraded app. However, some new features (for instance there's a search artist by long/lat + radius and search concert by location), would let us have a great opinion about it.

what the status of the XML dumps is?

This is honestly something that we've not paid much attention on during last months. I just verified that our daily task to build the xml dump still run succesfully, but I haven't verified the content of the xml itself. Can you verify that and eventually open another email thread on it?

[Mario Boikov]

I answer all together to the incoming questions:

assume that you still allow 'anonymous' API calls for the majority of the functionality

For understandable reason (I believe so...), the new api requires a client_id, which you can freely and easily obtain. Please, don't really see this as a barrier, because it isn't so!

Maybe this is a "no issue" but if I release an app under an open source license and provide my client id in the source code, would that be ok?

I mean, someone could just take my id and start to use it and abuse your service, would that affect me or my app in some way?

/Mario

[Myst]

Sounds really nice!

 

I think it's time to update my old Windows Phone 7 application to support Windows Phone 8 and Windows 8 :)

 

I'm looking forward to see the new documentation.

[Myst]

Why would you include your client in the source?

I mean - couldn't you build that application using your client id and publish the source without it?

[Mario Boikov]

Because I always need to make sure that I don't accidentally commit my client id. I don't want to maintain two git repositories, only one.

/Mario

--

[rjc]

On Thu, Mar 21, 2013 at 08:39:45PM GMT, Mario Boikov wrote:
> Because I always need to make sure that I don't accidentally commit my
> client id. I don't want to maintain two git repositories, only one.

Nothing a private branch with pre-commit and post-merge hooks couldn't
handle :^)

> /Mario

Regards,

Raf

[Mario Boikov]

:)

So how do I prevent people from looking at the source in my javascript/ruby/python desktop application? :)

[rjc]

On Fri, Mar 22, 2013 at 07:00:29AM GMT, Mario Boikov wrote:
> On Thu, Mar 21, 2013 at 08:39:45PM GMT, Mario Boikov wrote:
>
> > > Because I always need to make sure that I don't accidentally commit my

^^^^^^^^^^^^

> > > client id. I don't want to maintain two git repositories, only one.
> >
> > Nothing a private branch with pre-commit and post-merge hooks couldn't
> > handle :^)
> >
> > :)
>
> So how do I prevent people from looking at the source in my
> javascript/ruby/python desktop application? :)

You've jumped from "accidentally" to interpreted languages ;^)

If that's indeed the case, simply don't - require users to get their own
client ID vide, e.g. AcoustID[0].

[0] http://acoustid.org/

Regards,

Raf

[Mario Boikov]

On Friday 22 March 2013 at 20:13, rjc wrote:

On Fri, Mar 22, 2013 at 07:00:29AM GMT, Mario Boikov wrote:

On Thu, Mar 21, 2013 at 08:39:45PM GMT, Mario Boikov wrote:

> Because I always need to make sure that I don't accidentally commit my

^^^^^^^^^^^^

client id. I don't want to maintain two git repositories, only one.

Nothing a private branch with pre-commit and post-merge hooks couldn't

handle :^)

:)

So how do I prevent people from looking at the source in my

javascript/ruby/python desktop application? :)

You've jumped from "accidentally" to interpreted languages ;^)

I don't jump anywhere… I guess you can't see the irony in the answer (doing pre-commits and post-merges just to handle a client id). No matter how the source code is handled, I pointed out that it will still affect many desktop applications in the open source community.

If I have to care about a client id, I'll preferable create a unique Spotify player which people actually use. No one I've told about Jamendo know what it is… for them, registering a client id is out of the question. 

If that's indeed the case, simply don't - require users to get their own

client ID vide, e.g. AcoustID[0].

[0] http://acoustid.org/

Funny, but this is what actually happened to your service: http://oxygene.sk/2013/02/acoustid-invalid-api-key/

"I have made it really easy to get new API keys, in hope to avoid copying them from other open source applications."

Cheers,

 Mario

[Stefano Vettorazzi Campos]

If you're programming on Python or something like that, you can use environment variables.

Maybe only will be useful for web applications.

[samuel baudouin]

While there are thousands of way to solve the problem of committing
the client id ( gitignore being one of them ), to me it still doesn't
answer the question:
If I (developer) create an application (like a widget or an mobile
app) that would be used by other people, you wouldn't want to ask them
to create a client id. yes?

On the other hand, if they misuse the application (and the underlying
jamendo API) with my client id, then I would be held responsible for
it.

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

--
Samuel Baudouin

[Stefano Vettorazzi Campos]

I have not readed the documentation, but I think that works like all the actual APIs (Soundcloud, Facebook, Youtube, etc).

You have a client_id for your request to the API, but you can make a request to the API with a token of a user that granted permissions to your application.

For the API you're an application, and in consecuense you need to be identefied and authorized to make a request.

This way warrants a more stable and secure service, and easy integration for developers with experience in other APIs.

2013/3/27 samuel baudouin <osens...@gmail.com>

--
Samuel Baudouin

--
You received this message because you are subscribed to a topic in the Google Groups "jamendo-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jamendo-dev/9-FoXArSF7c/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jamendo-dev...@googlegroups.com.

[Vivien Genet]

Hi all,

Of course when you develop an application that will be used by other people, you don't need to ask them to create a client id. You need one client for one application.

This client id allow us to identify each application using our api and secure the final users and the api…

Moreover, in the devportal.jamendo.com, thanks to the client id, you have an access to the usage statistics of your applications.

And as explained by Stefano, if you want to access Jamendo account's data, you need to be "authorized" to do this by the final user to access his Jamendo's data (via the OAuth2 protocol explained here: http://developer.jamendo.com/v3.0/oauth2).

Vivien.

[drew Roberts]

On Thu, Mar 28, 2013 at 4:19 AM, Vivien Genet <viv...@jamendo.com> wrote:
> Hi all,
>
> Of course when you develop an application that will be used by other people,
> you don't need to ask them to create a client id. You need one client for
> one application.
> This client id allow us to identify each application using our api and
> secure the final users and the api…
> Moreover, in the devportal.jamendo.com, thanks to the client id, you have an
> access to the usage statistics of your applications.

Vivien,

I think the question was:

"Maybe this is a "no issue" but if I release an app under an open
source license and provide my client id in the source code, would that
be ok?

I mean, someone could just take my id and start to use it and abuse
your service, would that affect me or my app in some way?"

so, in an application where the complete source is open to the world's
view, how do you avoid others seeing the client id? Is there some
trick where the id only works with a binary with a certain signature?
(I think that is the issue being raised.)

all the best,

drew

http://freemusicpush.blogspot.com/

[rjc]

On Thu, Mar 28, 2013 at 11:12:54PM GMT, drew Roberts wrote:
> so, in an application where the complete source is open to the world's
> view, how do you avoid others seeing the client id? Is there some
> trick where the id only works with a binary with a certain signature?
> (I think that is the issue being raised.)

Not exactly. The source code can always be published without the ID and
only be included in the official binary. What the OP is concerned was
how to avoid the ID being abused by others if one publishes the
application in an interpreted language, i.e. Perl, Python, Ruby, etc.

> all the best,
>
> drew

Kind regards,

--
rjc

https://tools.ietf.org/html/rfc1855

[Mario Boikov]

Actually, it was more of what responsibility I have towards Jamendo of trying to "hide" my client id.

What would happen if someone uses my id. I mean, for an open source app it isn't that hard to figure out the id if you know where the id will be stored in the binary.

Cheers,

 Mario

[chris]

Yes Mario you are right, it is important NOT to make your client data (data = id and secret) available to the public. When you create an API account you get a Client_ID as well as a Client_Secret, try to not make those informations publicly available.

There are two scenarios for which you want to keep your client Data secret.

* The first one is when you publish your app source code on a plattform like for example Github. The goal here is to avoid committing your Client data but also other stuff like your Database access credentials and other data of a similar kind.

The solution to this is to create an ignore file that tells Git or SVN to NOT commit that file. You could have a blank configuration file with only the structure but no real data that you commit and another configuration file for production containing the real data but that you DON'T commit.

To exclude a file using SVN you have to:

http://stackoverflow.com/questions/116074/how-to-ignore-a-directory-with-svn

To exclude a file using Git you have to:

http://stackoverflow.com/questions/10744305/how-to-create-gitignore-file

* The second scenario, is when you want to send the Client_ID and / or Client_Secret to our API servers.

To be more secure, we could add some complex mechanisms, like requests signatures and such, but it would have made the usage of our API a lot more complex for you the developers and it would not even have cleared all the remaining "security problems". So as there is no real danger, because the usage of our API and our content are free for everybody anyway, we decided to keep it simple even though this takes into account that some kind of rate limit fraud is possible. The advantage of having a Client_ID is that we can show you nice stats in the developer account about your app usage. We don't want to punish you because you have a highly successfull app that does lot's of requests ;)

However, there are two things that are important:

First you should use an SSL connection to avoid man in the middle attacks, to get your Client_ID. It's up to you if you want to use SSL or not but we highly recommend it. SSL is actually only mandatory for the the OAuth Grant to get an access token.

The second advice is not to store the Client_ID and Client_Secret in the apps source code. A better way is to have a proxy server that sends the app client data to the app upon launch over a secured connection. It could also allow you to update your client data (without an application update) in case of a real problem...

[Mario Boikov]

Hi Chris,

Thanks for taking time to answering.

My main concern is actually what responsibility I have  if the id/secret accidentally get leaked?

For example, will my account be closed on jamendo?

[Robin Jespersen]

Hi,

is the app required to use v3 to participate in the contest?

I think $1000 is a nice prize for a widget or a small app. 

But to really use the full potential of the new API and building a more complex application there is a lot more work to do. 

So maybe you can offer a way for developers to earn money in the long run?

[Vivien Genet]

Hi,

Yes the contest is to promote the new api, so the applications must use the api v3.

But because the new api is still in beta, if you think there is some missing methods in the new api, you can suggest us new some new methods to create or new parameters in existing methods…

The beta period should be finished in fe weeks.

For the contest, it's a contest, not a job ;)

Thanks,

Vivien.

[Vivien Genet]

Hi,

Yes if you leak the account informations accidentally we might have to suspend your client_id, not to punish you, but to prevent the "stolen" account informations to get used in another application. Then you can get a new client_id, client_secret, … That's why we advise you to not store these data directly in the app, to be able to update them without updating the all the app… 

About your responsibility, If someone get your client_id, he will be able to use the read api, as if he had his own private client_id, no more. So it's useless and it's not really dangerous. The write api (setUser method)is protected by OAuth2, so to use it, you need the client_id and the client_secret (passed in ssl), but ALSO the access_token delivered when the final user accept to give an access to the application used. 

But legally, even for the write api, you may not be held responsible in case of hacking if you do reasonable effort to secure your application.

Thanks,

Vivien.

[Mario Boikov]

Thanks, now I finally got my answer :)

Cheers,

 Mario

[chris]

Hello All,

The Jamendo App Contest has started, for more information please check out this thread: https://groups.google.com/forum/?fromgroups=#!topic/jamendo-dev/OLIfBb4vmYM

jamchris

developer

jamendo.com

[Mohamed Maaizate]

Bonjour , je m’appelle Maaizate mohamed D origine du Casablanca , je suis débutant du programmation androïde j ai besoin d un projet d une application musical avec du téléchargement et qui comporte une bibliothèque non local Merci d avance . Bonne journée