OpenSimulator - User contributions [en]

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-08-15T12:26:33Z

Haravikk Mistral: /* X-Grid-Location Header */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-location-info</tt> be a better fit?).

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-08-15T12:25:53Z

Haravikk Mistral: /* X-Grid-Location Header */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Grid-Info: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-location-info</tt> be a better fit?).

User:Haravikk Mistral/RegionVerification

2017-08-14T22:22:35Z

Haravikk Mistral: /* Example */

= Overview =
== Problem ==
When receiving an HTTP request from a scripted object within an Open Simulator region, there is currently no means of verifying whether the request came from a legitimate source. For Second Life this is possible with a reverse DNS lookup on the IP address, if it has a valid <tt>simXXXX.<grid>.lindenlab.com</tt> address you can confirm that the request came from a legitimate source, but such a technique is not possible with Open Simulator based grids.

== Proposed Solution ==
This proposal is to provide a call-back mechanism with which a web-service, [[User:Haravikk Mistral/ExpandedGridInfoAvailability|knowing the source grid]], region name and simulator IP address, can query the source grid to verify whether the IP address and region name are valid, i.e- asking the grid to confirm that it has a simulator with a given IP address, hosting the given region name.

= Detailed Design =
== The Callback Service ==
Essentially what this feature boils down to is a callback service, implemented in much the same way as the [[GridInfo]] protocol. The proposed protocol would take the form:

<pre>http://example.org:9000/verify_region?name=Some%20Region&ip=123.123.123.123</pre>

To which the server would respond simply 'OK' if there exists a region named "Some Region", hosted by a simulator with IP address <tt>123.123.123.123</tt>, or else 'NO' if there exists no region by that name assigned to that IP. Thus a web service knows either that the combo exists (OK), doesn't exist (NO) or that the grid cannot or will not verify it (any other response).

== Example ==
The following example assumes the presence of the <tt>X-OpenSim-Location</tt> as proposed [[User:Haravikk Mistral/ExpandedGridInfoAvailability|here]]:
<source lang = "php"><?php
function fetch(array $array, $key, $default = null) { return (isset($array[$key])) ? $array[$key] : $default; }

// TODO: Verify basic headers first (since they require no callbacks)

if (isset($_SERVER['HTTP_X_OPENSIM_LOCATION'])) {
$uri = parse_url($_SERVER['HTTP_X_OPENSIM_LOCATION']);
if ((fetch($uri, 'scheme') == 'x-grid-info') || !$host = fetch($uri, 'host')) { die('Invalid URI'); }

$grid_address = $host . (($port = fetch($uri, 'port')) ? ":$port" : '');
if (!preg_match(';^/region/([0-9]*[^0-9/]+[^/]*)((?:/([0-9]+)(?:/([0-9]+)(?:/([0-9]+))?)?)?;i', fetch($uri, 'path'), $match)) { die('Invalid URI'); }

$region_name = urldecode($match[1]); $coords = [];
if (strlen($match[2]) && strlen($match[3])) { // 2-D coords
$coords = [(int)$match[2], (int)$match[3]];
if (strlen($match[4])) { $coords[] = (int)$match[4]; }
}

// TODO: Look up $grid_address and $_SERVER['REMOTE_ADDR'] in database, if they have been confirmed recently then don't do it again

// Host is unconfirmed, try to confirm it now
$curl = curl_init("http://$grid_address/verify_region?region=" . urlencode($region_name) . '&ip=' . $_SERVER['REMOTE_ADDR']);
curl_setopts_array($curl = [CURLOPT_RETURNTRANSFER => true, CURLOPT_FOLLOWLOCATION => true]);
$response = curl_exec($curl);
if ((curl_errno($curl) != 0) || (curl_getinfo($curl, CURLINFO_HTTP_CODE) != 200)) { die('Error occurred verifying region'); }
curl_close($curl);

switch($response) {
case 'OK':
// The grid confirmed the region and IP combo, we should cache it in our database to avoid repeated lookups
break;
case 'NO':
die('Invalid region/IP');
break;
default:
// TODO: Use some kind of fallback or "untrusted" behaviour instead
die('Unable to verify region/IP');
break;
}
}</source>

== Alternatives Considered ==
An alternative protocol for the verification would be to have the grid return some information about a region in an XML format. For example, a request for "Some Region" could return details such as its map location and IP, with the web-service extracting the IP itself to confirm. However, this raises the question of how much data should be revealed, and whether the ability to scrape by region name is desirable or not.

The proposed system above, while limited in the information it returns, requires the web-service to posses a valid region name and IP address, and can do nothing more than confirm that they are valid; if the IP address is incorrect then no data is returned (or some error, anything other than <tt>OK</tt> is considered to mean the combo was invalid or the operation is unsupported).

<pre>A DDOS attack against the grid servie is a very real possibility. A solution
needs to include ratelimiting</pre>

User:Haravikk Mistral/RegionVerification

2017-08-14T22:21:45Z

Haravikk Mistral: /* Example */

= Overview =
== Problem ==
When receiving an HTTP request from a scripted object within an Open Simulator region, there is currently no means of verifying whether the request came from a legitimate source. For Second Life this is possible with a reverse DNS lookup on the IP address, if it has a valid <tt>simXXXX.<grid>.lindenlab.com</tt> address you can confirm that the request came from a legitimate source, but such a technique is not possible with Open Simulator based grids.

== Proposed Solution ==
This proposal is to provide a call-back mechanism with which a web-service, [[User:Haravikk Mistral/ExpandedGridInfoAvailability|knowing the source grid]], region name and simulator IP address, can query the source grid to verify whether the IP address and region name are valid, i.e- asking the grid to confirm that it has a simulator with a given IP address, hosting the given region name.

= Detailed Design =
== The Callback Service ==
Essentially what this feature boils down to is a callback service, implemented in much the same way as the [[GridInfo]] protocol. The proposed protocol would take the form:

<pre>http://example.org:9000/verify_region?name=Some%20Region&ip=123.123.123.123</pre>

To which the server would respond simply 'OK' if there exists a region named "Some Region", hosted by a simulator with IP address <tt>123.123.123.123</tt>, or else 'NO' if there exists no region by that name assigned to that IP. Thus a web service knows either that the combo exists (OK), doesn't exist (NO) or that the grid cannot or will not verify it (any other response).

== Example ==
The following example assumes the presence of the <tt>X-OpenSim-Location</tt> as proposed [[User:Haravikk Mistral/ExpandedGridInfoAvailability|here]]:
<pre><?php
function fetch(array $array, $key, $default = null) { return (isset($array[$key])) ? $array[$key] : $default; }

// TODO: Verify basic headers first (since they require no callbacks)

if (isset($_SERVER['HTTP_X_OPENSIM_LOCATION'])) {
$uri = parse_url($_SERVER['HTTP_X_OPENSIM_LOCATION']);
if ((fetch($uri, 'scheme') == 'x-grid-info') || !$host = fetch($uri, 'host')) { die('Invalid URI'); }

$grid_address = $host . (($port = fetch($uri, 'port')) ? ":$port" : '');
if (!preg_match(';^/region/([0-9]*[^0-9/]+[^/]*)((?:/([0-9]+)(?:/([0-9]+)(?:/([0-9]+))?)?)?;i', fetch($uri, 'path'), $match)) { die('Invalid URI'); }

$region_name = urldecode($match[1]); $coords = [];
if (strlen($match[2]) && strlen($match[3])) { // 2-D coords
$coords = [(int)$match[2], (int)$match[3]];
if (strlen($match[4])) { $coords[] = (int)$match[4]; }
}

// TODO: Look up $grid_address and $_SERVER['REMOTE_ADDR'] in database, if they have been confirmed recently then don't do it again

// Host is unconfirmed, try to confirm it now
$curl = curl_init("http://$grid_address/verify_region?region=" . urlencode($region_name) . '&ip=' . $_SERVER['REMOTE_ADDR']);
curl_setopts_array($curl = [CURLOPT_RETURNTRANSFER => true, CURLOPT_FOLLOWLOCATION => true]);
$response = curl_exec($curl);
if ((curl_errno($curl) != 0) || (curl_getinfo($curl, CURLINFO_HTTP_CODE) != 200)) { die('Error occurred verifying region'); }
curl_close($curl);

switch($response) {
case 'OK':
// The grid confirmed the region and IP combo, we should cache it in our database to avoid repeated lookups
break;
case 'NO':
die('Invalid region/IP');
break;
default:
// TODO: Use some kind of fallback or "untrusted" behaviour instead
die('Unable to verify region/IP');
break;
}
}</pre>

== Alternatives Considered ==
An alternative protocol for the verification would be to have the grid return some information about a region in an XML format. For example, a request for "Some Region" could return details such as its map location and IP, with the web-service extracting the IP itself to confirm. However, this raises the question of how much data should be revealed, and whether the ability to scrape by region name is desirable or not.

The proposed system above, while limited in the information it returns, requires the web-service to posses a valid region name and IP address, and can do nothing more than confirm that they are valid; if the IP address is incorrect then no data is returned (or some error, anything other than <tt>OK</tt> is considered to mean the combo was invalid or the operation is unsupported).

<pre>A DDOS attack against the grid servie is a very real possibility. A solution
needs to include ratelimiting</pre>

User:Haravikk Mistral/RegionVerification

2017-08-14T22:15:37Z

Haravikk Mistral: /* Problem */

= Overview =
== Problem ==
When receiving an HTTP request from a scripted object within an Open Simulator region, there is currently no means of verifying whether the request came from a legitimate source. For Second Life this is possible with a reverse DNS lookup on the IP address, if it has a valid <tt>simXXXX.<grid>.lindenlab.com</tt> address you can confirm that the request came from a legitimate source, but such a technique is not possible with Open Simulator based grids.

== Proposed Solution ==
This proposal is to provide a call-back mechanism with which a web-service, [[User:Haravikk Mistral/ExpandedGridInfoAvailability|knowing the source grid]], region name and simulator IP address, can query the source grid to verify whether the IP address and region name are valid, i.e- asking the grid to confirm that it has a simulator with a given IP address, hosting the given region name.

= Detailed Design =
== The Callback Service ==
Essentially what this feature boils down to is a callback service, implemented in much the same way as the [[GridInfo]] protocol. The proposed protocol would take the form:

<pre>http://example.org:9000/verify_region?name=Some%20Region&ip=123.123.123.123</pre>

To which the server would respond simply 'OK' if there exists a region named "Some Region", hosted by a simulator with IP address <tt>123.123.123.123</tt>, or else 'NO' if there exists no region by that name assigned to that IP. Thus a web service knows either that the combo exists (OK), doesn't exist (NO) or that the grid cannot or will not verify it (any other response).

== Example ==
The following example assumes the presence of the <tt>X-OpenSim-Location</tt> as proposed [[User:Haravikk Mistral/ExpandedGridInfoAvailability|here]]:
<pre><?php
function fetch(array $array, $key, $default = null) { return (isset($array[$key])) ? $array[$key] : $default; }

// TODO: Verify basic headers first (since they require no callbacks)

if (isset($_SERVER['HTTP_X_OPENSIM_LOCATION'])) {
$uri = parse_url($_SERVER['HTTP_X_OPENSIM_LOCATION']);
if ((fetch($uri, 'scheme') == 'x-grid-location') || !$host = fetch($uri, 'host')) { die('Invalid URI'); }

$grid_address = $host . (($port = fetch($uri, 'port')) ? ":$port" : '');
if (!preg_match(';^/region/([0-9]*[^0-9/]+[^/]*)((?:/([0-9]+)(?:/([0-9]+)(?:/([0-9]+))?)?)?;i', fetch($uri, 'path'), $match)) { die('Invalid URI'); }

$region_name = urldecode($match[1]); $coords = [];
if (strlen($match[2]) && strlen($match[3])) { // 2-D coords
$coords = [(int)$match[2], (int)$match[3]];
if (strlen($match[4])) { $coords[] = (int)$match[4]; }
}

// TODO: Look up $grid_address and $_SERVER['REMOTE_ADDR'] in database, if they have been confirmed recently then don't do it again

// Host is unconfirmed, try to confirm it now
$curl = curl_init("http://$grid_address/verify_region?region=" . urlencode($region_name) . '&ip=' . $_SERVER['REMOTE_ADDR']);
curl_setopts_array($curl = [CURLOPT_RETURNTRANSFER => true, CURLOPT_FOLLOWLOCATION => true]);
$response = curl_exec($curl);
if ((curl_errno($curl) != 0) || (curl_getinfo($curl, CURLINFO_HTTP_CODE) != 200)) { die('Error occurred verifying region'); }
curl_close($curl);

switch($response) {
case 'OK':
// The grid confirmed the region and IP combo, we should cache it in our database to avoid repeated lookups
break;
case 'NO':
die('Invalid region/IP');
break;
default:
// TODO: Use some kind of fallback or "untrusted" behaviour instead
die('Unable to verify region/IP');
break;
}
}</pre>

== Alternatives Considered ==
An alternative protocol for the verification would be to have the grid return some information about a region in an XML format. For example, a request for "Some Region" could return details such as its map location and IP, with the web-service extracting the IP itself to confirm. However, this raises the question of how much data should be revealed, and whether the ability to scrape by region name is desirable or not.

The proposed system above, while limited in the information it returns, requires the web-service to posses a valid region name and IP address, and can do nothing more than confirm that they are valid; if the IP address is incorrect then no data is returned (or some error, anything other than <tt>OK</tt> is considered to mean the combo was invalid or the operation is unsupported).

<pre>A DDOS attack against the grid servie is a very real possibility. A solution
needs to include ratelimiting</pre>

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-08-14T22:15:04Z

Haravikk Mistral: /* Alternatives Considered */

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-08-01T11:21:00Z

Haravikk Mistral: /* X-Grid-Location Header */

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-08-01T11:19:10Z

Haravikk Mistral: /* X-Grid-Location Header */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location-info://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-info</tt> be a better fit?).

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-07-31T14:11:31Z

Haravikk Mistral: /* Alternatives Considered */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-info</tt> be a better fit?).

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-07-31T13:50:46Z

Haravikk Mistral: /* Overview */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-07-31T11:54:06Z

Haravikk Mistral: /* X-Grid-Location Header */

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether).

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to [[User:Haravikk_Mistral/RegionVerification|verify a region]].

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

User:Haravikk Mistral/ExpandedGridInfoAvailability

2017-07-31T11:53:06Z

Haravikk Mistral: Created page with "= Overview = == Problem == An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID eith..."

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether).

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

User:Haravikk Mistral/RegionVerification

2017-07-31T11:43:17Z

Haravikk Mistral: Created page with "= Overview = == Problem == When receiving an HTTP request from a scripted object within an Open Simulator region, there is currently no means of verifying whether the request ..."

= Overview =
== Problem ==
When receiving an HTTP request from a scripted object within an Open Simulator region, there is currently no means of verifying whether the request came from a legitimate source. For Second Life this is possible with a reverse DNS lookup on the IP address, and if has a valid <tt>simXXXX.<grid>.lindenlab.com</tt> address you can confirm that the request came from a legitimate source, but such a technique is not possible with Open Simulator based grids.

== Proposed Solution ==
This proposal is to provide a call-back mechanism with which a web-service, [[User:Haravikk Mistral/ExpandedGridInfoAvailability|knowing the source grid]], region name and simulator IP address, can query the source grid to verify whether the IP address and region name are valid, i.e- asking the grid to confirm that it has a simulator with a given IP address, hosting the given region name.

= Detailed Design =
== The Callback Service ==
Essentially what this feature boils down to is a callback service, implemented in much the same way as the [[GridInfo]] protocol. The proposed protocol would take the form:

<pre>http://example.org:9000/verify_region?name=Some%20Region&ip=123.123.123.123</pre>

To which the server would respond simply 'OK' if there exists a region named "Some Region", hosted by a simulator with IP address <tt>123.123.123.123</tt>, or else 'NO' if there exists no region by that name assigned to that IP. Thus a web service knows either that the combo exists (OK), doesn't exist (NO) or that the grid cannot or will not verify it (any other response).

== Example ==
The following example assumes the presence of the <tt>X-OpenSim-Location</tt> as proposed [[User:Haravikk Mistral/ExpandedGridInfoAvailability|here]]:
<pre><?php
function fetch(array $array, $key, $default = null) { return (isset($array[$key])) ? $array[$key] : $default; }

// TODO: Verify basic headers first (since they require no callbacks)

if (isset($_SERVER['HTTP_X_OPENSIM_LOCATION'])) {
$uri = parse_url($_SERVER['HTTP_X_OPENSIM_LOCATION']);
if ((fetch($uri, 'scheme') == 'x-grid-location') || !$host = fetch($uri, 'host')) { die('Invalid URI'); }

$grid_address = $host . (($port = fetch($uri, 'port')) ? ":$port" : '');
if (!preg_match(';^/region/([0-9]*[^0-9/]+[^/]*)((?:/([0-9]+)(?:/([0-9]+)(?:/([0-9]+))?)?)?;i', fetch($uri, 'path'), $match)) { die('Invalid URI'); }

$region_name = urldecode($match[1]); $coords = [];
if (strlen($match[2]) && strlen($match[3])) { // 2-D coords
$coords = [(int)$match[2], (int)$match[3]];
if (strlen($match[4])) { $coords[] = (int)$match[4]; }
}

// TODO: Look up $grid_address and $_SERVER['REMOTE_ADDR'] in database, if they have been confirmed recently then don't do it again

// Host is unconfirmed, try to confirm it now
$curl = curl_init("http://$grid_address/verify_region?region=" . urlencode($region_name) . '&ip=' . $_SERVER['REMOTE_ADDR']);
curl_setopts_array($curl = [CURLOPT_RETURNTRANSFER => true, CURLOPT_FOLLOWLOCATION => true]);
$response = curl_exec($curl);
if ((curl_errno($curl) != 0) || (curl_getinfo($curl, CURLINFO_HTTP_CODE) != 200)) { die('Error occurred verifying region'); }
curl_close($curl);

switch($response) {
case 'OK':
// The grid confirmed the region and IP combo, we should cache it in our database to avoid repeated lookups
break;
case 'NO':
die('Invalid region/IP');
break;
default:
// TODO: Use some kind of fallback or "untrusted" behaviour instead
die('Unable to verify region/IP');
break;
}
}</pre>

== Alternatives Considered ==
An alternative protocol for the verification would be to have the grid return some information about a region in an XML format. For example, a request for "Some Region" could return details such as its map location and IP, with the web-service extracting the IP itself to confirm. However, this raises the question of how much data should be revealed, and whether the ability to scrape by region name is desirable or not.

The proposed system above, while limited in the information it returns, requires the web-service to posses a valid region name and IP address, and can do nothing more than confirm that they are valid; if the IP address is incorrect then no data is returned (or some error, anything other than <tt>OK</tt> is considered to mean the combo was invalid or the operation is unsupported).

User:Haravikk Mistral

2017-07-31T10:19:09Z

Haravikk Mistral:

= About =

Haravikk Mistral is a virtual worlds veteran, with nearly 12 years as a resident of Second Life, as well as minor involvement with many other virtual world efforts. After irreconcilable differences with Linden Lab staff Haravikk quit Second Life as of 20th July 2017 to pursue the freedom and openness of Open Simulator based grids, with a keen interest in helping to develop them.

Haravikk has been a professional programmer for over 8 years, but has been programming and scripting for the better part of 15 years, with experience in a wide range of languages including C, C++, Objective-C, C#, Swift, Java, Javascript, PHP and Ruby, and of course LSL.