Skip to content
TORNLIFE More

Player managed API permissions

Started by Halflernation [847751] on in API Development.

4 replies · 193 views · thread synced · 4 days ago · View on torn.com
About this thread

Posts archived: 5 / 5 posts (100%) · the total is Torn's reply count + the opening post at the last fetch

Counted by TornLife from the archived posts.

Archived posts
5
Discussion span
→
People posting
3
Likes on archived posts
14
Posts by staff, officers and moderators
1
Authority score
72 / 100
Historical score
24 / 100
Story score
33 / 100
Engagement score
52 / 100
Halflernation [847751]
Idea:
Implement per-key access permissions (simple on/off) in order to control which types of data are available to be accessed personal user fields/data.
EDIT: e.g. USER / Available fields: networth, bazaar, display, inventory, hof, travel, events, messages, education, medals, honors, notifications, personalstats, workstats, crimes, icons, cooldowns, money, perks, battlestats, bars, profile, basic, attacks, attacksfull, revives, revivesfull, stocks, properties, jobpoints, merits, refills, discord, gym, timestamp
One can `allow` a given access key to have access to the `root` (User) field plus: `bars`, `profile`, `cooldowns`, `refills`.

Goal:
Allow for greater privacy whilst giving space for value-added tools through API implementations.

Concept:
Each player is able to have more than one api access key (a limit can be imposed of course, even a small limit like 2 or 3).

A player has the ability to manage which types of data/fields a given api key has access to.

E.g. player statistics: one can choose to disclose 'bars' and 'cooldowns' but block access to all other fields (other than parent).

Benefits:
Avoid the downside of sharing one's API key with 3rd parties (allowing access to ALL data).
Be in control of what data is gathered.
Tools can get the exact data they need without having access to more private data.
Tool developers and users trust in each other is increased. In turn, spurring more development with more players willing to give access of certain (and only some) data.

Impact:
Depending on implementation, number of API calls may increase as the total amount of calls allowed for a single player.
Say: if a given player has 2 (two) api access keys and both are being used by external programmes, currently the max calls/sec are per key. This effectively has the potential to double the number of calls being made to the api endpoint.


Apologies I'm on a phone writting this, is the concept clear and why this benefits the community in the sense that it allows players to control which data stays private? (In turn opening up some data to a given end to tools/developers).
EDIT: typos and syntax. minor additions.

H+
DeKleineKobini [2114440] Committee Committee
I can see the benefit, but the fact that you would want 100 calls/key, is undoable, as they are trying to lessen the amount of calls (hence the cache).
I think a shared call limit is better, so it would be the same as now, but with better security.
Halflernation [847751]
I agree DeKleineKobini.
I don't want 100 calls/key. I'm just analysing the current impact of such implementation based on the way they currently limit the number of calls.

Making such change (shared limit amount of calls) would be ideal.

H+
L4suicide [15699]
I've suggested this before, but I also acknowledged this is hard to put in for Ched as you need to build permission system etc

A simpler way may be to have 2-3 API keys per user
* Bars and stats
* Bars, stats and news/events
* All
Halflernation [847751]
I'd be happy with a discussion on what could be such a smaller subset of groups yes.
2 or 3 could totally be enough.

To spot and manage activity I would be fine with a couple keys providing access to: a. Bars; and b. Status (Okay, Hospital, etc...).

Then have one key with complete access.

Depending on backend, a class-object-oriented class would not tske much time to implement.

H+