mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

I have added a new branch, lp:~mugle-dev/mugle/dev-api, which contains our
implementation of the developer-facing API. So far, it has two new things:

   - A new page doc/dev/api.rst which contains a description of the API. We
   won't document the interface here just yet. Just keeping a high-level
   description of the API. Eventually I expect this will have examples, and
   possibly the full interface.
   - A new service KeyValueService, which we will use to trial the new API
   approach for developers.

We should fully implement KeyValueService (including on the database) and
test it out to see that it works OK, before going ahead with the remaining
services.

Refer to the Google doc "Initial API designs" for the full list of methods
we are planning to support. This includes:

   - Getting the User ID and name.
   - Badges / achivements (have to decide what we will call them; internally
   at least they are achievements).
   - High score

I also just had a dreadful thought which is, even though we are using
GameToken to prevent games from interfering with one another in this API,
what about the rest of the APIs? I forgot about this security problem. Even
though we are using cookies to ensure that no user can access another user's
stuff through the API, I forgot that we will effectively be giving all of
the games full access to the client-side API (i.e., our "internal" one).
Therefore, any game that a user runs can effectively take any action on
behalf of the user. This is what we get for not having a separate domain per
game!

It is a pretty hard problem to solve. We may just need to vet the games
fully before we allow them onto the server :/