Write API / User API Token (or OAuth?)

[smb]

Do you have plans for a user-write API? (raid actions: raid signups/cancel, comments would be enough)

i have plans (no idea if i ever find time to do this) to write an android application for raidmembers - thats why a personal private access token would be needed (i think its much easier to implement than some sort of oauth mechanism - which would be totally oversized).

so basically:

• user installs app on phone
• app wants raidplaner URL + user (!) access token
• user can browser / signup / cancel raids or write comments

admin support is not needed (manage raids, manage chars, manage options, ...).

optional: user settings (set auto attend, enable vacation mode)

UPDATE: if you dont have time for this - i could try to implement it (should be only a time-issue since there is no frontend stuff involved)

[arnecls]

Well, a write API will require a login mechanism, as information about the current user is required throughout the system.

In principle you can already do this. The only problem might be implementing a cookie storage. Just in case you want to try, have a look at the following files:

login.js (startLogin / initLogin) hash.js (to see which algorithm requires which hashing method) main.js (reloadUser)

To see how to request / post things search for "asyncQuery" in the script folder. The relevant query/post requests are usually at the end of each script.

The only thing that will not be as nice as with an official API is that the messagehub api is considered private and can change with each update. So you will have to keep an eye on the changes in this repository.

[smb]

Are you opposed to a "token" system for users?

additional api parameters: user (userid? username?), usertoken (works just like the global token but for this specifiy user, would require a db change though - new column in the user table)

i thought about using messagehub but since its considered "private" - this would break apps using it and a permanent token (submittet with every user-action) would make things much easier (no session/cookie tracking etc.).

[arnecls]

I need to think that through. The current API was originally created read-only because of security concerns. Passing a userid alone would be not be very secure. So if there ever is a write-only API it will probably use a system similar to oauth, i.e. logging in with username / pass and retrieving a token that can be used for a certain time.

[smb]

Yes - userid only would be insecure (beyond imagination) - i thought about a userid + personal pi token combination:

apihub.php?query=raid &userid=123 &usertoken=336e56573c28abdc &action=signup &raidid=321 &charid=222 &role=5

and user is able to generate/regenerate (new) private api tokens in his profile settings (lost phone, revoke access, ...). would be much less effort than oauth and thats how its done in other apps as well

[arnecls]

A personal, private token could indeed be a solution. You won't need a userId though as the token will be unique by itself in 99.9% of the cases. And the remaining ones can be catched with a MySQL constraint. The only thing that I can think of is that users might find it more cumbersome to copy over a large string of random characters than to simply enter their username and password. From a programmer's perspective a private token is of course much simpler.

[arnecls]

I will add this to the 1.3.0 feature list. I suspect this will be a quite large change as I don't want to maintain two full APIs (public and private) forever. So both APIs need to be merged somehow. And while at it, there is that "make it a real REST API" task in my head that would fit into this task, too. But I still have to wrap my head around the implications of this.