LSL Wiki : XMLRPCDiscussion

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are
XML-RPC is working, but with the restriction that the script cannot initiate a remote procedure call - it can only answer them. This means, you cannot use XML-RPC to communicate directly between objects. According to a posting from Mark Linden, this will remain the case until they have figured out a way to let LSL scripts do XML-RPCalls without having malicious scripters abuse the feature.

Ezhar thinks they could probably safely enable it for connecting to their own hosts, not the rest of the net, to allow object-object communication within SL. -- Ezhar

Chris thinks that if LindenLab wants to call the functionality they give us "XML-RPC", they should give us a full implementation, not some crippled parts of a full implementation. Malicious scripters? Please post the scenario where fully implementing XML-RPC will somehow cause grief.

Several: Portscanning using XML-RPC requests. Denial of service attacks against any kind of TCP-based service (webservers, mailservers etc.). Any of these things will cause a) people to get very angry at LL and b) people to block LLs IP range. So lets say someone from SL will rez a few hundred objects that each send XML-RPC requests as fast as they can to a webserver hosted by the british telecom. Webserver craps out, BT people get pissed, probably tell LL to stop it immediately and meanwhile block LLs IP range to protect themselves. Result: Nobody using BT as their internet provider can log into SL anymore, LL facing pissed BT users, and possibly legal trouble. Banning the offender from SL will not influence the outcome of this - it's too late, the damage is done. Worse yet, if this happens two or three times (not unlikely), LL can easily loose their credibility on the net and end up having many more providers block their IP range as preventive measure. -- EzharFairlight

I stand corrected. --Chris

Proposed solution to this problem: Check the servers response for the correct message-id:

If the server is not responding/timing out, responding with an invalid XML-RPC reply or responding with the wrong/missing message id (from llSendRemoteData) an error should be returned to the script that initiated the XML-RPCall. The next XML-RPCall from the same script would execute only after a delay (10 - 30 seconds is not unreasonable). Such an error could be sent to the script via a remote_data event with a new constant, for example REMOTE_DATA_ERROR - this way the script can handle an error without delay and then retry the call (and only now the delay kicks in, preventing flooding a service with requests).

In the case of a well-formed reply with the correct message-id, the next call would not be delayed. This would ensure that a server unaware of llRemoteData XML-RPCalls could not be flooded with requests while a server that handles them and returns the correct message-id (and thus can be expected to be a valid target for such requests) can still communicate with the script without delay.

This solution would prevent the abuse of LSL's XML-RPC client as denial of service mechanism, with the exception of attacks on valid XML-RPC/llRemoteData servers. A fairly acceptable risk that could be further lowered by including the scripts owners UUID in each XML-RPC call and thus making tracing the offender very easy.

-- EzharFairlight

maybe keep track of ip's of XML-RPC/llRemoteData servers and delay any request that is sent to close to another request; have each ip have a 10 request buffer, and if the buffer fills, throw an error. Then any time data comes back from that server send 2 requests from the buffer if they are present ignoring delay period but not ignoring some global cap. That way you could never exceed the capacity of the server or flood a server that doesn't send responces. Also would need the sims to tell each other which ip's they were hosing so someone doesn't leverage all 210+ sims resources (maybe a good idea to do the same thing for email). -- BW

Here's Testing Bard's opinion on the subject:
"This problem has already been addressed and solved by Macromedia.

To prevent this same security issue and potential absue, Flash Player 7 changed its security model to only allow TCP and HTTP connections back to the exact address (host.domain) serving the application (SWF). -- Except -- If you specify a host/domain outside the serving address, it will check for a security policy file, crossdomain.xml in the website root.


<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
<allow-access-from domain="*" />

Before an XML-RPC connection is opened to a foreign server, the policy file on the corresponding web server is checked. That policy can then be cached by SL for 1 hour, 1 day, or whatever they decide. Therefore there is NO DoS potential for any site unless they explicitly allow XML-RPC connections from SecondLife.

For servers that do allow connections from SL, it is unlikely anyone but the server-admin & script author would know the address, unless they make it available for public use. The security file could also be extended to only allow connections from objects owned by a particular owner, or particular sim.

<allow-access-from domain="" />
<allow-access-from domain="" />

The other piece prevent denial-of-service attacks (against another site or the SL sim server resources itself) is to simply limit the number of concurrent XML-RPC calls a given object can make. Also, have a finite XML-RPC object pool on each server limiting the number of concurrent XML-RPC calls the entire sim can make, insuring the integrity of server resources.

Polling the servers from outside poses a much higher and unmanageable server load risk than does initiate connections in-world. " [Testing Bard]

Here's Chris' responce to Testing Bard's suggestion:
"I would love to see outbound RPC calls enabled, and this seems like a plausable solution. The only problem I have with it is how it can be actually implemented.

Ideally, to request security policy information, I'd like the linden server itself to make an XML-RPC request to the destination domain.

Something like, calling a remote function named "isRpcConnectionAvailableFor" with a String argument containing the hostname of secondlife's XML-RPC server ("" or something like that. The Linden domain and the function the Linden server calls to check its permission have to be known published values). isRpcConnectionAvailableFor will then return a String (or int value) containing "true" or "false" (or 1 or 0, if you go with ints). If the xml-rpc destination address doesn't recognize (or doesnt respond to) "isRpcConnectionFor", then the Linden server would assume the responce is "false". The Linden server would then store the destination domain's responce and purge it every x amount of <minutes, seconds, hours, days>.

That way, people on the Linden end and us SL scripters dont have to jump through hoops or make huge modifications to implement this secure system." [Christopher Omega]

Here's Xugu's thoughts:
"Would it be possible for the system to block outgoing requests to hosts from which it has not yet received XML-RPC requests? Ideally, have a specific command hosts could send to tell the Linden severs that they're willing to accept XML-RPC requests?" [Xugu Madison]

Grim's thoughts
I'm pretty much against Strife's recommendation, and even Testing Bard's solution has some problems. Xugu's idea still wouldn't prevent DoS attacks against VALID XML-RPC servers that are intended for use with SL.

I'm working on setting up a remote database site for storage and retrieval of data for use in SL objects. Problem is, I need ways to ensure that only "subscribers" are accessing the database. I think I could work around Testing Bard's solution if it involved the object-owner level security. It would really suck if somebody got pissed off and DoS?'ed my data server, and I had no way to lock out that user's requests without locking out ALL of my users in the process.

I don't want it throttled or capped at all, especially globally. Sure, a global cap may work if I have 10 subscribers, but what happens when I have 100? 1000? [GrimLupis]

Grim, where's Strife's recommendation? What about my idea? :) -Chris

Umm, I don't remember what that comment was in response to. Oops. The potential problem with your idea, Chris, is the timeout period. What happens if there's an internet hiccup, or I'm rebooting my server, and a request comes in? How long will it be before my address will be cleared from the blacklist? And we have to keep in mind the side-effects that we'll get if there's a minor glitch. How hard is it going to be to code fault-tolerance into our little 16k scripts? Also, I'm keen on the idea of being able to allow/deny access to services based on user name/key. Otherwise there's no way for me to ban a bonehead without hurting my legit users in the process. [GrimLupis]

See my comment about Bard's "" (or that would solve the users problem... just add the users to the permissions file when they sign up. [ResunaOddfellow]

They did a nice job making the order of the integer and string values inconsistent in the various functions too ;-p

Here are some forum posts about XML-RPC:
Title Description
XML-RPC Implementations A post about XML-RPC clients in different programming languages.
Not another XML-RPC Thread!?! A post discussing the crippling of XML-RPC and possible solutions.


22-07-2004 Questions?!?! I don't know this stuff. Do XML/RPC, SOAP and CORBA all do essentially the same thing? Is this a subset or a superset of what is accomplished by COM, COM+ and DCOM on Microsoft Machines but this stuff is cross platform? Am I close or am I way behind and way off here? Could someone comment on the differences and similarities of these technologies for ignorant people like me? Also, which technologies are taking root now and which are being scrapped? What should I spend my precisous time learning and what is no longer worth the trouble? Thank you everyone. -- TinkerThetan

I just posted the following into the Feature Suggestions forum; I'll copy it here also.

One possible way to avoid [spamming external sites] would be to have a potential out-calling site register itself with SL, which would then allow scripts to make XML-RPC calls to that site. For example:

My fictitious site,, sends an XML-RPC request to second life, using a specific "registration" channel (e.g. 01234567-baad-c0de-d00d-0123456789ab). The IntValue of the request would be the number of seconds for which the registration is valid, possibly with a maximum (say 86400 seconds, 1 day). The StringValue of the request would be a security code which would be used to allow only authorized objects to talk to the XML-RPC server.

The registration process would record the expiration time of the registration, the security code, and the IP address from which the registration request was received.

After the site is registered, objects within SL could start sending XML-RPC requests to the site. The "channel" of the llSendRemoteData call would have to be the security code listed in the registration, and the hostname portion of the URL for "dest" would have to resolve to the same IP address that was recorded for the registration; if either of these requirements is not met, the XML-RPC request would fail [silently or otherwise].

By restricting access to sites that have already registered themselves with SL, you prevent random DoS attacks, and by including a "security code", you prevent unauthorized access to private XML-RPC servers. (public servers could use a null security code to allow general access).

This was a quick thought this morning, and so there are quite possibly security flaws in this model that I haven't considered; if you think of any, please discuss them here

- Neo

HuntingHare was once a network admin (for 8 years) in his first life. Must point a few things out:

1: Places that create XML-RPC resources are already vulnerable to XML-RPC DoS. How they deal with that is their own site-specific policy.
2: Linden Labs acts as an internet service provider in this case -- they can't be responsible for what their users do with the tools, as long as they're responsive to complaints. Since they have positive economic user identification (including a credit card!) for their players, they can be responsive. (block certain credit cards from using XML-RPC, as an example, since there's a finite universe of credit cards -- and LL can certainly log all usage of the XML-RPC function, and make the number of XML-RPC connections per hour a world-wide shared pool, limiting it by the number of primitives that the script creator has, or by the number of instantiated objects that were created by the script creator in the event of a widely-merchandized script, or by an XML-RPC tax for the script creator, or...)
3: Authentication mechanisms are properly placed on the resource itself, not mechanisms for accessing the resource. (I can understand the concept of wanting to minimize the abuse of a 'proxy' system -- but sheesh, this is supposed to be a functional economy, and it would be a good thing to help reduce the amount of money in the world, if they need it.)

The proper way to look at this isn't as a technical problem, but as an economic problem. XML-RPC requests are a precious resource -- and it's in LL's (and the players') best interests to reduce the abuse of them, else they become less precious as more sites block SL's servers.

Since users of XML-RPC already have to authenticate to the XML-RPC servers they're trying to use, forcing a proxy authentication system (or any kind of system that increases the load on LL or the XML-RPC site owner) just doesn't work well. Putting a L$ pricetag on a certain number of XML-RPC requests would be a start, but I'm not sure that that would be useful either. Minimizing the number of objects per owner that can be accessing a certain data source at a time would be another good thing. (though why LL doesn't implement SOAP requests as well -- for compatibility with such things as Amazon and Google -- is beyond me... unless I just answered my own question.)

Anyway. I've been up for about 15 hours, and I'm heavily caffeinated, so these are just some rambling thoughts -- but these are thoughts designed to help put the problem in the correct domain, instead of a heavy-overhead technical concept. (I must admit, I would very much like to be able to post to my blog from within SL. Write up a notecard, ship it off to my custom blogpost script, and make it easier to do things in-world.)

How about simply proxying the XML-RPC calls through the client? That way only that client is affected if they try to DOS another server.

- Noodles

I, OrangeE, concurr with HuntingHare probably because of having a similar background in network administration. I've been considering making data in the real world represented in SL. For example, I am working on a 'mood ball' that could change colors based on changes in financial markets or other parameters. I was working on making a nice script that would not make RPC requests unless an avi was nearby, but because I can only do XML responses I'll have to push data into the ball from the outside world frequently without knowing if it's worth updating or not. I suppose my point is that without a working llSendRemoteData Second Life is creating an inbound-spam problem of lots of inbound RPC requests for objects that do not need updates.

BTW, can't users already send E-Mail out through the system? Has there been any problem there with spamming?
Comments [Hide comments/form]
I'm pretty much against Strife's recommendation, and even Testing Bard's solution has some problems.

I'm working on setting up a remote database site for storage and retrieval of data for use in SL objects. Problem is, I need ways to ensure that only "subscribers" are accessing the database. I think I could work around Testing Bard's solution if it involved the object-owner level security. It would really suck if somebody got pissed off and DoS'ed my data server, and I had no way to lock out that user's requests without locking out ALL of my users in the process.

I don't want it throttled or capped at all, especially globally. Sure, a global cap may work if I have 10 subscribers, but what happens when I have 100? 1000?
-- GrimLupis (2004-06-24 13:36:13)
Could e-mail somehow be used as a workaround to the issue?
-- SgeoNewbie (2004-07-20 21:34:03)
Temporarily, yes. However, the non-event-oriented nature of email makes it unreliable and slow for the many purposes true outbound xmlrpc would be used for. Not to mention that llEmail currently blocks script execution for 20 seconds.
-- ChristopherOmega (2004-07-20 22:21:47)
For object to object communication, there should be something like llMessageObject(key object, integer num, string something) or something along those lines...
-- SgeoNewbie (2004-07-22 18:51:23)
I have an idea. The XML-RPC server would itself send a sort of message telling what keys are allowed to send requests to it.
-- SgeoNewbie (2004-07-26 19:17:03)
Sgeo, the problem with that is that it still leaves us relying on eMail-RPC for "registration." How is the RL server going to know what channels/object keys it's willing to accept data from, until the object is cabable through some interface of "registering" itself?

LL's mail server proved a couple of weeks ago to be not the most stable system in the barn. I don't like having it as the only viable option for initiating communications with an out-world system.
-- GrimLupis (2004-08-17 14:22:36)
GrimLupis: If you have 100 or 1000 subscribers, you're getting into the "death of the low barrier to entry" aspect of the Internet. Such as... well, webcomics that become popular suddenly become much more expensive to maintain.

It's up to YOU to ensure that your database recognizes bad calls as early and quickly as possible, and returns appropriate errors.

It'd be nice if a "magic cookie" could be set in the response that SL's servers could listen for and block access from the same script. Perhaps a key of 'llQueryID' or something that SL's servers automatically put into each request, and then your own server could send an XML-RPC request to some magic place that LL sets up to block queries to your database from the same source (owner or creator) as the source of the 'bad' calls.

It's certainly a technical challenge to create a mechanism by which XML-RPC resources can request not to be spammed. It's an economic challenge, though, to reduce the capabilities of a bad script to damage the entire game.
-- HuntingHare (2004-09-09 16:08:00)
We're still stuck with a kluge-upon-kluge implementation here. Perhaps its time to rethink a bit.

The problem, as I see it, is that currently you need to use XML-RPC for inbound communications to Second Life, and email for outbound communications. This creates a situation where you have far too many points of failure, and creates a significant amount of work for anyone using Java/JSP, PHP, and so on.

What I propose is a function:

string llTouchURL(string url, integer length)

Basically, the Second Life server would go to the URL provided (say, ?!?) and return up to ?length? characters from the URL. By using the web, this creates a simple 2-way communication device invoked from within SL to any web server out there, without having to set up something involving, for example, compiling PHP-IMAP and XML-RPC into PHP, which is a long, arduous, tedious process. Also, many shared web servers out there do not provide anything close to this functionality ?out of the box?, so if you don?t have root, you?re up the creek without a paddle.

This function raises the problem of possible spam / DOS attacks. Here?s my solution. From the Second Life members web site, under MY ACCOUNT, create another link, ?White listed URLs? (or something to that effect ? I?m not a copy editor!) It would be empty by default, with an ADD URL button.

If I click ADD URL, and enter http:, SL would look for a file,

Within that file would be, one per line, the names or keys of any avatars who are allowed to send and receive using llTouchURL from http:* URLs. Any time a user tries to add this URL to his or her ?White List?, it would check that file to verify that the key or name is present in that file, thus creating a situation where you can verify that the URL being used WANTS to communicate with Second Life. Then when the function is called, simply do a ?SELECT * FROM white_list_url WHERE avatar_key = ? ? + object_owner_key + ?? and url = ?? + passed_url_from_llTouchURL + ???

If it returns true, you will know to execute the function otherwise, perhaps pop a ?Communication with URL not permitted. Check your white list.? error.

I can?t really think of any cons, other than requiring a fair amount of work on the Linden Lab end. :-)

For pros, I see a much easier way to provide 2-way communication, a much lower entry level, a much quicker deployment time, and a much more stable environment. Instead of having many potential points of failure (SL itself, SL?s inbound/outbound communication, XML-RPC, email server, email parser, programming language/web server) you have two (SL itself and your programming language/web server). You also allow similar functionality to people who purchase shared space and can't afford their own full servers.
-- FlipperPA (2005-01-25 07:05:11)
I have another suggestion.

When checking the crossdomain.xml file, check using a pseudo-domain based on the name of the user running the script. For example, if I was running it it would check against "". That way you could either just allow your users in by naming them in the file, or allow anyone in, or just block abusers.

This would require least work from Linden and least work on the server side, I think.
-- ResunaOddfellow (2005-08-11 11:21:05)
Whoops, I missed that TestingBard already included this in his suggestion, though using first.last would allow clever things like allowing "*". :)

Either of these schemes would seem to answer GrimLupus' comment "Also, I'm keen on the idea of being able to allow/deny access to services based on user name/key. Otherwise there's no way for me to ban a bonehead without hurting my legit users in the process."

As for timeouts: if the server is down you can re-check the server even every few seconds without that being significant load, and checking once a minute would be more than fast enough to keep the blacklist from being a problem. Just cache the result for however long that timeout is so scripts simply fail out until it comes up again.
-- ResunaOddfellow (2005-08-11 11:38:23)
Why try blocking an attack? it WILL happen! oh yes it will, nomatter what you do.

if LL gets in trouble they just gotta point the angery people in the direction of the one who made the objects to spam the server.
THEY will recive punishment not LL.

i will PM a linden with examples for how you could do the spaming.
so i dont give any potential-abbusers any ideas... :)
-- GilesCela (2005-11-01 14:49:45)
Ok, here's a straightforward way of doing it. Create a new item type. Make it cost the standard L$10 to create or modify. Store a URL in it that represents an external server. Any object that wants to talk to that server needs to have that object in its inventory. Probably also want to add in a restriction that ONLY non-modify scripts by the same creator can access it. Access-check the server when modifying it, with some standard call (to that server) giving the name of the person creating/modifying the URL. Only need to access-check it the one time.

If the server at a later time returns an error indicating access is no longer permitted, store that in the URL item, and block access to it for 10 minutes or so. That prevents DoS, while not blocking things for too long in case of a temporary server problem. Don't block it in case of no response (or only block it for a short amount of time, e.g. 30 seconds).

This object type should be explicitly a singleton, like textures, sounds, and animations, with the difference being that it can be modified. The change would then be reflected in all "copies". The only restriction on propagation delay (if any) on the new value would be that once a new value has started to be used by an object, it should never revert to the earlier value.

Of course, what you really want with something like this is shared libraries - a URL item could be a special case of a shared library, in which case you could make library routines the only place access to the server could be implemented; any additional security checks could be made by the library itself (would need some additional support to determine creator/modifier of the script calling it). Such a shared library would need both shared and instance (per script) variables, along with initialization routines for each (shared/instance).
-- SylvarGould (2005-11-12 13:55:14)
I'd like to back up a moment. Why XML-RPC? Why not SOAP? This would give SL objects access to lots of web-services already out there. It would then be possible to build SL environments which are virtual views of the net ("Cyberspace Deck" was a term bandied about many years ago). The potential there is enormous.

That does rule out the the Macromedia-style solution (which requires that the server be SL savvy). Other possibilities are requiring that the user confirm any outbound connections from their machine. ("Always block", "Block this time", "Allow this time", "Always allow") made by an object. That would be stored on a per-destination-host basis, and they could review the list. However, as it becomes more common, that could get annoying. Also, a URL isn't enough. The object would also have to provide a reason. A further option would be to require that the object-owner register all hosts it will attempt to connect to with LL. But that could rule out useful stuff like Blog posting/reading that could potentially point anywhere.

I'm not perfectly happy with putting the burden on the user--since they are likely just to say "yes" no matter what. But it might help. The other side of course is that LL needs to be able to centrally disable access to certain hosts immediately. So although connections need to go from the client for scalability reasons, there still needs to be centralized control, and perhaps even centralized logging.
-- MooshGoodliffe (2006-01-07 09:44:05)
Just as a developer I'd love to see XML-RPC built into SL, I like the ideas of doing SOAP a bit more, to allow direct access to some of the more nifty features... Imagine a script that could go out and connect to google's SOAP API, and retreve spelling suggestions, or suggested sites on subjects, or amazon's linking to books, or a psudo-realtime stock ticker, pulling data live off the web (well, with the 20 min delay). LL seems to take the approch that they are a provider, and I like the suggestion that LL should take action mostly in responce to complaints. I think perhaps doing throttling based on the number of players in a sim or the number of players that interacted with the object, so you can do like X+Y*(Number of players) per min or per hour. That would allow sims to do more requests as the player load goes up. Perhaps the limit could be raise on larger plots of land too. I do think that when this is finalized, it should make sure that you can interoperate with existing webservices, because I see many more uses if players don't have to host their own RPC services.
-- KunnisBasiat (2006-06-24 00:33:27)
Okay here's another misguided crack at the problem:
How about enabling RPC calls for the following specialized subset:
1. RPC calls can only be made by objects attached to an agent
2. They must identify the agent
3. The server must recognize that agent
i.e. agent is registered at the remote site.
4. Server can blacklist agent and/or report abuse to LL

This might limit things but at least a bunch of applications will work.

And additional mod might allow further applications:
1. Owners, and only owners, of land can place objects on their land that do RPC calls (in otherwords, not allowed for non-owner objects in sandboxes or anywhere else)
2. The owner of the land is identified in the RPC call in the same way as an agent above
3. The server must recognize the owner (owner is registered on the server)
4. Server can blacklist owner and/or report abuse LL

And, of-course, group membership would never qualify you as an owner (otherwise we have a massive loophole).
-- BlueVale (2006-11-01 10:03:07)
lol just throttle outgoing XML-RPC just like llEmail
-- AnorcaCalamari (2007-01-07 20:58:15)
A simple llHTTPRequest out, and XML-RPC in is the best solution, though that is probably known since this article is really old.
-- (2007-05-16 20:04:13)
<a href= >bdsm domination submission</a> [url= ]bdsm domination submission[/url]<a href= >LESBIAN FOOT FETISH</a> [url= ]LESBIAN FOOT FETISH[/url]<a href= >friend gate hot mom</a> [url= ]friend gate hot mom[/url]<a href= >female foot domination</a> [url= ]female foot domination[/url]
-- (2007-06-11 15:57:52)
<a href= >bdsm domination submission</a> [url= ]bdsm domination submission[/url]<a href= >friend gate hot mom</a> [url= ]friend gate hot mom[/url]<a href= >female foot domination</a> [url= ]female foot domination[/url]<a href= >LESBIAN FOOT FETISH</a> [url= ]LESBIAN FOOT FETISH[/url]
-- (2007-06-12 14:20:42)
Hello!!! fetish foot
http: foot fetish
<a href= >fetish foot</a>
<a href= http: >FOOT FETISH STORY</a>
<a href= http: >foot fetish</a>
-- (2007-06-17 08:53:08)
Hello!!! female domination
http: female domination video female foot domination
http: male submission female domination
<a href= >female domination</a>
<a href= http: >female domination video</a>
<a href= >female foot domination</a>
<a href= http: >male submission female domination</a>
-- (2007-06-18 15:55:16)
Attach a comment to this page: