DM/Player Authorization in the Authentication API
Andrew Reutter
For the most part, this should be a matter of documentation.
Authorization will be enforced on the iplay4e servers, so if someone
attempts to take an illegal action such as edit a character they're
not allowed to, the server will reject the request. Client code
should be written to conform to the documented guidelines about who is
authorized to do what.
More inline below...
On Tue, Apr 13, 2010 at 9:03 PM, Christopher Brind <bri...@brindy.org.uk> wrote:
> Right now I presume in a campaign only the DM and the Player can update the
> characters?
Actually, only the player can. We have it on the roadmap to allow the
player to specify one of three choices when adding their character to
a campaign:
- Me and the DM (default)
- Me only
- Anyone in the campaign
Note that implementation of that feature is distinct from our API
doc/develop effort, though it may receive greater priority as a
result. No, scratch that, it will be pretty much essential for DMs to
be able to update the characters in their campaign.
> Is it possible to have a scenario where the DM can make it so that he has to
> approve changes made by a player, or disable certain changes all together?
> Examples:
> - a player uses a healing surge inappropriately - the DM might deny that
> change
> - the DM disables the player's ability to update their equipment / money
Hrm. I'm not sure if that's something we want to do or not. The
second item, at least, might encourage mutiny ;-> Perhaps the
absolute simplest way to address it would be to add a fourth option to
the permission options list from the last point:
- DM only
That would allow new players, or players in a campaign where it's
understood that the DM will do all the state tracking, to add their
characters in a way that enables your use cases. It also avoids the
need for us to write a whole approvals subsystem.
What do you (or anyone else) think of that approach?
Cheers,
Andrew
> I don't know if I'm inadvertently jumping in to the detail of the polling
> API, or possibly in to client implementation territory, but is the above
> supported and if not, do you think it's worth doing?
> Thanks,
> Chris
>
>
> On 14 April 2010 02:51, Andrew Reutter <andrew....@gmail.com> wrote:
>>
>> Hi folks,
>>
>> I've been threatening this for weeks, and am finally getting off my
>> lazy butt to do something about it. Time to talk about the combat
>> API. There are now multiple third party products that integrate with
>> iplaye to load character and even campaign data. They're stunningly
>> cool - but we can do better.
>>
>> The basic idea is for iplay4e to be the master source for
>> character-related combat data, with an arbitrary number of other
>> products able to simultaneously read from and write to that data in
>> real-time. I should be able to run a combat using inCombat while
>> displaying a map using Masterplan, while one of my players is viewing
>> their character on iplay4e with their iPhone, another is seeing their
>> sheet embedded on Epic Words, and another is using Google Wave to view
>> all the characters in the campaign. Furthermore, when a change is
>> made to a character using any of those mechanisms, it should be
>> visible in all the products without undue delay.
>>
>> To pull this off, we'll need a set of APIs, some of which already
>> exist and are documented, some of which need docs, and some of which
>> remain to be specified.
>>
>> These already exist, complete with docs on the main group page:
>>
>> - Authentication API enabling products to retain iplay4e sessions
>> using Google Account credentials.
>> - Search API enabling the listing of campaigns and characters for a
>> user, the listing of the characters in a campaign, and ad-hoc queries.
>>
>> These also exist currently but lack documentation (volunteers? ;-):
>>
>> - Data API describing how to consume character and campaign XML. This
>> is for static values like max HP, defenses, and so forth. The docs
>> are currently in the XML itself; I would love for it to move to the
>> group for consolidation and data size reasons.
>> - Initialization API describing how to retrieve and consume starting
>> character state such as current hit points and conditions. Not
>> documented, but reverse-engineerable because iplay4e itself uses it.
>> - Update API enabling products to push changes made to characters.
>> Also reverse engineerable.
>>
>> Finally, this API is missing:
>>
>> - Polling API enabling efficient retrieval of state updates for
>> multiple characters simultaneously.
>>
>> Before we dive into the specifics of any individual API, I'd like to
>> nail down this high level list. Am I missing anything?
>>
>> Cheers,
>> Andrew
>>
>>
>> --
>> To unsubscribe, reply using "remove me" as the subject.
>
>