rojo
rojo copied to clipboard
rojo-rbx
Add Headless API
Closes #638.
You can read the API docs here: https://github.com/boatbomber/rojo.space/blob/headless-api-docs/docs/headless-api.md
FWIW I'm not sure this needs any kind of permissions system at all (me and lpg talked about it briefly), what's the thought process of that?
FWIW I'm not sure this needs any kind of permissions system at all (me and lpg talked about it briefly), what's the thought process of that?
The API holds a lot of power over the user's project, and we don't want malicious plugins to be able to impact it without the user's knowledge and consent, much like Roblox has a permission system for plugins that attempt to write scripts or web requests.
If any plugin can access it (since it's through _G) then I guess I get it, but would need to recheck what the permission scopes are
I also wonder if there's an attack vector of changing _G.Rojo from another plugin and trying to hijack access from something else, making this whole process pointless (if you have any other plugins)
I also wonder if there's an attack vector of changing
_G.Rojofrom another plugin and trying to hijack access from something else, making this whole process pointless (if you have any other plugins)
(Sorry for late reply, missed the notification)
I don't think that attack vector would be effective, because the middle man would need to get permissions for all the APIs anyway. For example, let's say I write "EvilRojo" and make it grab _G.Rojo and overwrite it with my own, so all Rojo API traffic flows through EvilRojo before being passed to the original API so that behavior doesn't seem amiss. The user would see that EvilRojo is requesting all permissions (since otherwise it can't pass calls through) and additionally, all the actions would show EvilRojo as the source.
No since everyone could edit _G.Rojo there is no protection agenst editing it or is there?
I'd like to mention my studio-wally plugin which utilizes this experimental API to allow installing wally packages directly from studio. https://github.com/fewkz/studio-wally This headless API feature is very useful!
Overall, I like the design of this but I am concerned about the potential for abuse it gives third parties. As an example, there is nothing stopping me from going rawset(require(game.Rojo), "API", {Notify = function() print("i am being malicious") end}).
This isn't a concern for most people, since I don't imagine most devs are just installing random plugins, but it's still a real problem that I want to avoid. Do you think there's be consequences to exposing the API as a userdata with a metatable instead of a table?
Do you think there's be consequences to exposing the API as a userdata with a metatable instead of a table?
Will take a fair bit of rejiggering but that should work and close some potential attack vectors. Good call.
I'm curious why
RequestAccesslets the users pick out which APIs they want to allow. I can't think of a case where you would want to give a plugin only some of the permissions it's asking for and for a plugin to only use some of the permissions it wants.
Honestly, I can't remember my original reasoning so I'm gonna redo this to be all or nothing to create a simpler UX & DX. Thanks for bringing it up.
Reviewing the docs made me realize I have a more logistical comment for this PR: it exposes an ApiContext, which means we need to care about it a lot more than we current do. This applies to the Rust side of things too.
This isn't a problem, but it means we need to consider it in versioning and should probably also document both sides.