(apologies if this ends up posting multiple times, I mistook the 
user-activation e-mail as confirmation I could post, instead of following the 
link first, then on my second attempt used the wrong damn e-mail address 
*facepalms*)


I'm currently looking at porting a set of web-services from Second Life for use 
with Open Simulator based grids, and my current challenge is validating that an 
llHTTPRequest() comes from the grid and region that it claims to. For Second 
Life requests all I had to do was a reverse DNS lookup on the sender's IP 
address, to see if it ends with agni.lindenlab.com <http://agni.lindenlab.com/> 
or aditi.lindenlab.com <http://aditi.lindenlab.com/> depending upon the value 
for X-SecondLife-Shard, as this confirmed the server was valid, which means I 
can then reasonably trust the other headers.

For Open Simulator grids this obviously isn't possible. So what I'd like to be 
able to do is instead require that requests include a header with grid 
information, such as the grid's login URI (as obtained by the 
osGetGridLoginUri() function), and then somehow perform a call-back to the grid 
asking it to confirm if the sender's IP address is currently hosting the region 
that it claims the request is from.


To break it down a bit more:

1. A script in Haravikk's Region, hosted at 123.123.123.123 sends an 
llHTTPRequest() to my web-service with the following key headers:
X-SecondLife-Region: Haravikk's Region (1000,1000)
X-OpenSim-Region-UUID: 12345678-1234-1234-1234-123456789012
X-OpenSim-Grid: http://mygrid.com/login <http://mygrid.com/login>; 
nick_name=my_grid; name="My Grid"
2. My web-service doesn't recognise the IP as a host for Haravikk's Region on 
my_grid, and so sends a call-back to my_grid asking whether the IP 
123.123.123.123 is currently hosting a region named "Haravikk's Region".
3. If the grid confirms that it is, my web-service can store a note of this for 
some reasonable time to avoid repeated requests, and serves up content as 
normal, knowing that the request comes from the grid and region that it claims 
to (or at least, that the grid was willing to vouch for it).


What I would like to know is:
1. Is something like this currently possible? The only other way I could think 
to do this would be to write some kind of bot to try to connect to the region 
through the given grid but that would be incredibly heavy-weight, and I think 
would only work if the region was accessible via the hyper-grid (since I can't 
have specific login details for every potential grid).
2. If it isn't currently possible, what would it take to make it so? I'm a 
programmer myself so wouldn't mind working on adding this if I have to, but I 
have no familiarity with the code and am only really starting to get a grasp 
for the structure of Open Simulator, so I'm not sure what the best place to add 
such an externally facing service might be?
3. Is it worth looking into adding the X-OpenSim-Grid header as a standard 
feature either way? It's obviously pretty easy to generate yourself via script, 
but seems like it'd be a useful addition for Open Simulator llHTTPRequest() 
calls.


In case it helps, the idea with my web-service is that data will be stored with 
an awareness of which grid it belongs to; my purpose in validating the region 
with the grid is to make it harder for a request to be spoofed as coming from a 
given region/grid combo. While grids like osgrid obviously allow ad-hoc regions 
to connect and disconnect, I would at least be able to confirm that a region 
did exist, and osgrid was willing to vouch for that region's IP; if a grid 
doesn't provide confirmation, then I know that the request is being spoofed (or 
sending old details, or the grid doesn't want to play ball, but either way 
gives me reason to reject it).

I think this could help a lot for writing web services for use across grids.

Any help is greatly appreciated!
- Haravikk
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

Reply via email to