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 :/
-- Mailing list: https://launchpad.net/~mugle-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~mugle-dev More help : https://help.launchpad.net/ListHelp
