I apologize if this question has already been addressed on the list or
the API documentation, though I haven't been able to find an answer on
either. I am working on a desktop app that utilizes the
RememberTheMilk API. Since this program is Open Source software, I
will be distributing the source. My question is: is it acceptable to
put my API Key and Shared Secret into the source code, or does this
compromise the key? I don't understand whether distributing the Shared
Secret would pose a problem. I'd appreciate this clarification in
light of OSS.

It seems to me that the problem would be app spoofing:  someone could
take the API key and shared secret, and create a malicious
application.  They would still need to get hold of a token.

So I would also appreciate some "how to" and guidance on this matter.

I thought a little about this, and so far all I've come up with is:
- The API key isn't sensitive.  It's exposed when a user is asked to
authenticate an app anyway.
- The shared key IS sensitive - you definitely don't want to make this
public.
- One solution: you could implement a "signing service".
    - the open-source app could be distributed with the api_key
hardcoded
    - each time it wants to talk to RTM it posts to the signing
service first asking for an appropriate hash given the params it's
about to post
    - this lets you keep the shared key secret
    - access to this service would have to be gated by your own
username/password authentication, avoid abuse
    - there are some nasty drawbacks:
        - every post to RTM first requires a post to your own service
=> bandwidth issues
        - higher latency of each operation from a user's perspective
        - having a whole new service to create a login account on
isn't desirable for users
- I can't think of any other solution that doesn't involve new support
built into RTM.

-will

On Jul 10, 12:54 pm, Stian Hole <stian.h...@gmail.com> wrote:

Sorry for the delay.

For example, if you're building a Yahoo widget targeted at end-users,
I'd include the API key and shared secret with it.

If someone "borrows" this key/secret for another app, they'd still need
the end-user token to access a user account, and the ability to convince
an end-user that this new app matches up with the description,
screenshot, etc on the API authorization page for new users.

If the rogue app breaks the rules, we can throttle specific users based
on a (api_key, token) pair (or other variations thereof).

If you're developing language bindings or an installable open source web
app, then you shouldn't include your key/secret. Instead, you should
tell the developer/user of the binding/web app to request their own key
from RTM.

I hope that helps, and makes sense. :)