Skip to content
TORNLIFE More

[Request] API Comments, and API Verification

Started by Helcostr [1934501] Wiki Editor on in API Development.

6 replies · 332 views · thread synced · 8 days ago · View on torn.com
About this thread

Posts archived: 7 / 7 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
7
Discussion span
→
People posting
4
Likes on archived posts
49
Authority score
71 / 100
Historical score
42 / 100
Story score
38 / 100
Engagement score
60 / 100
Helcostr [1934501] Wiki Editor
PART 1: API COMMENTS - DEBUGGING

Add an API comments section in the api call. This will help with debugging what programs are what from a community dev's perspective.

There is a false sense of security if the comments is slapped with the words "DoctorN", and so the comments probably should be hidden away so that only devs can find it. Probably the lowest barrier of entry would be requiring opening the dev console, maybe seeing the not displayed comment in the html using display:none. Or maybe hiding the comment in the JSON of the preferences.php?ajax=getApiData (similar to how the id of faction news is hidden in the json as well).

PART 2: API VERIFICATION - SERVER BASED APP SECURITY

Add the ability for a community dev to opt into obtaining a separate "dev key".

This key is designed to authenticate the dev's SERVER BASED APPLICATIONS as applications that the dev has full control over (and while it's not suppose to be a sign of trustworthiness, it's a sign of "this is the definite user who is accessing your data."

Conclusion

These two combined should help with both debugging (especially userscripts) as well as provide some level of authentication for server based applications (so that remote IP addresses are demystified).
N-kay [1947169]
I don't see the point of API comments (anyone feel free to explain), but application verification has a lot of potential.

Verification would probably be manual and hand picked, maybe later automated if they can come up with a robust, abuse-free approach.

Verified applications could...
  • have to send both app and user key together in request
  • be allowed only a certain part of the API - transparent to the user. (The application can do this and that, but not these).
  • have a dedicated pool of API calls of their own to use, no user key required
  • show up seperately in "recent API calls" with app name. Call all other API calls unverified, might make users think twice
  • maybe have access to "secret" sections of the API
  • receive other special treatment, depends on app
Torn could then...
  • show a list of verified apps, their usage( XX calls made by YY user keys in 24h), the owner.
  • more easily track abuse and revoke access of the entire application
  • maybe punish owners of abusive applications harder (which they'd have to agree to beforehand)
Fogest [2254826]
I don't get the API comments either. I think the API logs should just show the user-agent string of the client requesting the API data. Maybe on hover so that we can figure out who is making API calls frequently with our keys.

In addition to this, something like an official torn proxy tool would be amazing. Where we could generate app specific keys with specific data permissions. I am sick of giving a bunch of people full access to a ton of my account data just so I can get access to useful tools to help in Torn.
Helcostr [1934501] Wiki Editor
On the subject of comments:

Comments are for when the abusive api system is your own network, but u don't remember what tools u installed / u don't remember what tools u wrote.

Combined with verification, it (if visible to the public) can also help users [relax/be on guard] and understand why their API is being used by a certain dev user.

On the subject of verification:

As long as the user can't reverse engineered the dev secret, then we are good. Similar to Oauth2, but without the client auth.

On the subject of security:

Ched has already declined more complexity to the user's end (with comments against multi key system, making the API too convoluted to the normal user). I do not want to open this can of worms, but if our community is strong, then we can probably get Ched to change his mind. This is NOT the direction of this suggestion just yet: baby steps.
N-kay [1947169]
Comments are for when the abusive api system is your own network, but u don't remember what tools u installed / u don't remember what tools u wrote.

That's kind of like asking your car manufacturer to fix your car because you keep going too fast.

If you hammer the API from any number of endpoints so carelessly and don't even remember, you should just pull the plug and change keys.
Helcostr [1934501] Wiki Editor
We have way too many drivers in this one car. And so we need pseduo logs of who drove the car. Even if the logs can be forged. If logs are being forged, then it's time to reset the key.

I come into a new environment, and i see someone hammering their own api. i do the best i can to salvage the situation by telling the user to turn off everything... but that 1 call is still happening.

I am no idiot developer. But there are idiot developers out there. So this acts as a catch for those idiot developers (i am looking at potentially the torn widget, cuz I'm hearing bad things about that app)
Refl3xX [1672091]
api comments is... i dnk even what u mean. read th** 10x over.... 10x i read it i failed to compile what u even said in my head.

but VERIFICATION is SOOOO IMPORTANT! how do we tell somple thing "which user" without hauling out their entire profile thru the api main key?

but yes. it IS important to KNOW which BOT.

In that. I would suggest. Bot writers get their OWN API key specificillay for theyr registered bot & use it a s a user-agent string

r+