Allow external connections to DFHack remote services. #1173
Conversation
|
Is this merge-ready? Also, are the conflicts irrelevant (i.e. can I just go with the develop branch versions of the RFR files), or are there important changes here? It appears that spoofing localhost's IP isn't realistic, but as long as DFHack still listens only on 127.0.0.1 by default, this should be fine (anyone enabling this feature should understand the risks). |
|
I'll have to take a look. I want both the enabled state, as well as the port, to be settable in a json file. I'll have to check to make sure they are. |
…erUnsafe # Conflicts: # plugins/proto/RemoteFortressReader.proto # plugins/remotefortressreader/remotefortressreader.cpp # scripts
|
Cool. Looks like the only build issue was a missing script, probably due to submodule stuff I can handle. |
|
@JapaMala did you check? |
|
Looks like it's in there. Should be fine. |
|
Getting this on a fresh install on OS X: I suspect it has something to do with the config file not existing. |
|
I'll look into it. |
This needs a bit more work before it's ready to merge, but I figured I'd get some feedback here anyway.
The idea is that the more dangerous functions, like the "run any command" or "run arbitary lua code" functions are barred if they don't come from localhost, while relatively safe functions can be run from other computers or devices, like reading the map, or setting designations, etc.