Jump to content

[Proposal] Remote NPC script loading


iwillnot

Recommended Posts


  • Group:  Members
  • Topic Count:  12
  • Topics Per Day:  0.00
  • Content Count:  51
  • Reputation:   23
  • Joined:  04/28/12
  • Last Seen:  

Objective

Load scripts not from your standard `rathena/npc` directory but instead, from a remote server via http/https.

Design goals

  • Parameters for NPC script loading would be: (a) remote http/https URL (b) support for request header for authorization purposes (e.g. API key)
  • The downloaded file must be a single `.txt` file
  • The file is then hashed by the server, and cross-checked to ensure data consistency
  • The file's existing supported versions can be checked (returns JSON array)
  • Caching - Can download the files into a git-ignored directory on the actual server for caching purposes
    • If the requested file and version already exists in cache AND the file's hash matches the hash of the server, no need to download the file again
    • NOTE: Not entirely sure yet if I want the download to be perform the caching, because it goes against the whole idea of "not having the source code on your server" aspect.

Benefits

By adding this source capability, we:

  • enable RO developers who produce intellectual property (NPC scripts in this specific case) to have some control over their IP.
    • NOTE: It is still possible for  RO developer scammers to sell shady scripts/sell scripts that aren't theirs, grant their customers temporary access, and then remove access from their customers.
  • enables RO developers to sell licenses to their IP, and revoke license (disable API token) after some validity period (e.g. 3 months).
    • Opens up the opportunity for a monthly or yearly pricing of their NPC script licenses.
  • enable RO developers to share their rAthena server folder to co-developers without risk of accidentally granting them access to other IP that they aren't supposed to share.
    • e.g. RO Admin builds server. RO Admin buys 10 NPC scripts, with license to use in one RO. server. RO Admin hires RO Support dev. RO Support dev granted access to rAthena server files because they have work to do. RO Support dev now has access to npc scripts they didn't purchase, and is a vulnerability.

 

Related source code

Specifically, the following files need to be changed/extended:

int npc_addsrcfile(const char* name, bool loadscript) - in src/map/npc.cpp

image.thumb.png.4e6bb782f8134b704b0a26f8a8dbbfe8.png

Probably adding a new function called

int npc_addremotesrcfile(const char* resource_url, char* resource_hash, char* resource_version, bool loadscript) - in src/map/npc.cpp

Usage

Potentially using it on an npc script would look like this:

image.thumb.png.2733060f9b334618fab24760b9e925f3.png

image.thumb.png.26644b84834d092e3138cb3eaf5072de.png

remotenpc: <URL> <VERSION> <HASH>

remotenpc: https://some-ro-developer.com/servers/some-ro-server-1/scripts/my-private-script 1.0.0 70460b4b4aece5915caf5c68d12f560a9fe3e4

Thoughts

I wanted to get the thoughts/vibe of the community before pushing through with this idea.

I know that we're an open-source community that wants to encourage full-sharing of source code. But I think that the strict constraints that follows from that is something to consider. It limits the number of developers you can onboard onto your team, or needing to think about whether "you trust everyone".

I think doing this (a) encourages developers to produce great NPC scripts, (b) enables developers to make good money on it, (c) positions rAthena or whoever to start up some kind of dependency management/NPC scripts platform (similar to npm, or composer) where server owners can shop for NPC scripts.

  • Securely designed remote script access
  • enable developers to focus on writing NPC scripts
  • opportunity for NPC script customization layer
  • developers can now easily scale up their marketing on some dependency management/NPC scripts platform
  • well-paid developer
  • happy developer
  • more scripts
  • happy community

I will definitely be exploring this on my own, but I wanted to know what the community thinks about it.

PS: Potentially a source of revenue as well for rAthena to sustain itself. I am open to the idea of assisting in the architecture design for that platform.

Edited by iwillnot
  • Upvote 5
  • Love 1
  • MVP 1
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

  • Group:  Forum Moderator
  • Topic Count:  33
  • Topics Per Day:  0.01
  • Content Count:  1268
  • Reputation:   381
  • Joined:  02/03/12
  • Last Seen:  

It could be interesting way of not actually distributing scripts. Perhaps for the purpose of dynamic updates or some kind of reseller prevention (even though they're being cached).

Yeah I'm for it.

Link to comment
Share on other sites

  • 1 month later...

  • Group:  Members
  • Topic Count:  3
  • Topics Per Day:  0.00
  • Content Count:  149
  • Reputation:   24
  • Joined:  02/11/16
  • Last Seen:  

Sounds risky. The lack of access to the source code poses a significant security risk (e.g. leaving backdoor access or sql queries that can be injected). 

Perhaps rA could have a code review committee that will only publish scripts in the marketplace that have been reviewed and tested to be error-free and exploit-free.

Great idea nevertheless.

Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  53
  • Topics Per Day:  0.01
  • Content Count:  411
  • Reputation:   260
  • Joined:  04/25/12
  • Last Seen:  

Concept idea its nice if emulator had an script engine encryption...

I don't see how this is secure if is just print the script to get it or put a breakpoint to get all script code when it loads.

And as Neffletics pointed, could be so dangerous for bigger server where you could add malicious code without knowledge of the admin.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...