Difference between revisions of "Plugin Separate Process"
Dr Scofield (talk | contribs) |
Gigs Taggart (talk | contribs) (Cleanup and expansion) |
||
| Line 1: | Line 1: | ||
== | == Local Network Port == | ||
A different approach that also looks quite interesting as it provides a lot of flexibility is to add just enough code to the SL client that it will forward all SL comms packets to a local network port and will accept packets to the SL grid but also to the view itself via that same local network port. | |||
Plugins would connect to that local network port and get to see all packets. also, they could inject packets both for the grid as well as for the viewer. | |||
== | == Packet Format == | ||
A unicode-based, "human-readable" encoding of the packets would allow us to use almost any computer language known to AV-kind: a shell script could be a plugin! One suggestion is to use XML format. The XML format has several downsides, however, not the least of which is performance. | |||
== plugin lifecycle == | == plugin lifecycle == | ||
Plugin should only live for the duration of a session. a plugin starter in the client (in the worst case that could be done as a shell script wrapper around the SL client itself) that goes through a $HOME/.secondlife/plugin.d directory and starts all plugins in that directory in alphabetical order (00-plugin-1, | |||
05-plugin-2, ...). | 05-plugin-2, ...). | ||
On shutdown the client will just send a "GOOD NIGHT" message out over the socket interface --- causing the plugins to shutdown. | |||
== | == Making life harder for attack scripts == | ||
We can make the port number random: the client (or wrapper script) picks a random available port number, passes that in to the secondlife client (if we are using a wrapper), and also as a startup argument to the plugins. | |||
In addition, we can generate a randomized password for each SL session and pass that in to the client and plugins and it becomes rather difficult to run an JS XMLHTTPRequest attack... | |||
JS XMLHTTPRequest attack... | |||
== | == Advantages == | ||
* | * Minimal code changes | ||
* | * Very flexible: write your plugin in perl, python, java (fortran anyone?) | ||
== | == Disadvantages == | ||
* | * No filter: quite a bit of (local) traffic | ||
* May be difficult or slow to create new UI using this method. | |||
* Latency is a concern with user-interactive plugins, especially if something with a lot of overhead like XML is used. | |||
[[Category:Feature Requests]] | [[Category:Feature Requests]] | ||
Revision as of 10:45, 22 February 2007
Local Network Port
A different approach that also looks quite interesting as it provides a lot of flexibility is to add just enough code to the SL client that it will forward all SL comms packets to a local network port and will accept packets to the SL grid but also to the view itself via that same local network port.
Plugins would connect to that local network port and get to see all packets. also, they could inject packets both for the grid as well as for the viewer.
Packet Format
A unicode-based, "human-readable" encoding of the packets would allow us to use almost any computer language known to AV-kind: a shell script could be a plugin! One suggestion is to use XML format. The XML format has several downsides, however, not the least of which is performance.
plugin lifecycle
Plugin should only live for the duration of a session. a plugin starter in the client (in the worst case that could be done as a shell script wrapper around the SL client itself) that goes through a $HOME/.secondlife/plugin.d directory and starts all plugins in that directory in alphabetical order (00-plugin-1, 05-plugin-2, ...).
On shutdown the client will just send a "GOOD NIGHT" message out over the socket interface --- causing the plugins to shutdown.
Making life harder for attack scripts
We can make the port number random: the client (or wrapper script) picks a random available port number, passes that in to the secondlife client (if we are using a wrapper), and also as a startup argument to the plugins.
In addition, we can generate a randomized password for each SL session and pass that in to the client and plugins and it becomes rather difficult to run an JS XMLHTTPRequest attack...
Advantages
- Minimal code changes
- Very flexible: write your plugin in perl, python, java (fortran anyone?)
Disadvantages
- No filter: quite a bit of (local) traffic
- May be difficult or slow to create new UI using this method.
- Latency is a concern with user-interactive plugins, especially if something with a lot of overhead like XML is used.