Difference between revisions of "User:Infinity Linden/OGP Test Cases"

From Second Life Wiki
Jump to: navigation, search
m (Authentication Test 2.6 - Select Failure of an Account Identifier with a Multiple Agents and a Hashed Authenticator)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''note: this is a brief note for informational purposes. it's eventually going to be "cleaned up" and moved to a more appropriate place on this wiki.'''
+
* '''note: this is a brief note for informational purposes. it's eventually going to be "cleaned up" and moved to a more appropriate place on this wiki.'''
 
+
* '''note: this is a branch from the original "OGP" Test Case page. PyOGP Test Cases are defined at [[User:Saijanai_Kuhn/OGP_Test_Cases]]'''
 
= Introduction =
 
= Introduction =
  
Line 13: Line 13:
 
Well... that's how it's supposed to be... In the real world, "running code" trumps written specifications, and probably will continue to do so. And that's one of the reasons we have the interop tests; properly written test cases succinctly communicate abstractions introduced in written specifications. So rather than viewing the SLGOGP spec and these tests as separate, think of them as being two sections of the same document.
 
Well... that's how it's supposed to be... In the real world, "running code" trumps written specifications, and probably will continue to do so. And that's one of the reasons we have the interop tests; properly written test cases succinctly communicate abstractions introduced in written specifications. So rather than viewing the SLGOGP spec and these tests as separate, think of them as being two sections of the same document.
  
= Test Fixtures =
+
= Base Tests ( Test 0.* ) =
  
== Login Test Fixtures ==
+
Many OGP messages take the form of an LLSD message serialized to XML and POSTed to an URL somewhere via HTTP (or HTTPS.) In the ideal world, HTTP would be free from error. But as it turns out there are many ways in which a HTTP request could fail, especially if your implementation of OGP uses proxies, load balancers, n-tier service architectures, etc. These tests are intended to ensure your client library properly communicates HTTP errors, assuming your client library has a standard technique for handling and recovering from such errors.
  
{|style="background:white" width="100%" cellpadding="5"
+
It is entirely possible that ''your'' client library does not handle such errors cleanly. This is not a failure, per se, but we strongly encourage implementers to expose an interface to client applications allowing exceptional events to be communicated through the client library and to the application.
  
|- style="background:lightgrey;"
+
== Base Test 0.0 - Return an Exception when Accessing a Non-Existent Resource ==
| valign="top" colspan="9"| '''0. login host fixtures'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| This is the "stock" login host for initial OGP beta roll-out. This is the host which receives authentication requests.
+
  
|- style="background:lightgrey;"
+
This test simply posts a properly formatted login request to an URL that does not exist. We anticipate a HTTP 404 result code, or at least that's what ''we'' would return if you sent a request to an undefined URL. In an ideal world we would test a resource from each resource class to ensure client library code handling each message properly propagates the "Not Found" exception. However, in the interests of alacrity we're only describing this test in terms of the agent_login resource class.
| valign="top" width="10%" |
+
| valign="top" colspan="8" | 0. login.aditi.lindenlab.com
+
  
|- style="background:lightgrey;"
+
So, test 0.0 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.404 (the canonical undefined agent domain), the client library produces a "HTTP Not Found" exception.
| valign="top" colspan="9"| '''1. agent domain fixtures'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| This is the "stock" agent domain host for initial OGP beta roll-out. This machine hosts capabilities granted after successful authentication.
+
  
|- style="background:lightgrey;"
+
== Base Test 0.1 - Return an Exception when Accessing a "Broken" Resource ==
| valign="top" width="10%" |
+
| valign="top" colspan="8" | 0. agent0.aditi.lindenlab.com
+
  
|- style="background:lightgrey;"
+
This test posts a properly formatted login request to an URL that has been preconfigured to return a HTTP 500 result code.
| valign="top" colspan="9"| '''2. region fixtures'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| These are two "well defined regions" within Linden Lab's beta test grid. Note there are no "well defined regions" outside Linden Lab's administrative domain. Anyone want to add themselves to the list? OSGrid? Bueller?
+
  
|- style="background:lightgrey;"
+
So, test 0.1 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.500 (the canonical broken agent domain), the client library produces a "HTTP Internal Server Error" exception.
| valign="top" width="10%" |
+
| valign="top" colspan="8" | 0. sim1.vaak.lindenlab.com:13000
+
  
|- style="background:lightgrey;"
+
== Base Test 0.2 - Return an Exception when Accessing an "Unavailable" Resource ==
| valign="top" width="10%" |
+
| valign="top" colspan="8" | 1. sim1.vaak.lindenlab.com:13001
+
  
|- style="background:lightgrey;"
+
This test posts a properly formatted login request to an URL that has been preconfigured to return a HTTP 503 result code.
| valign="top" colspan="9"| '''3. agents'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| There are currently 32 "standard" agents for testing. The agents represent all combinations of the five factors: accepted TOS, read critical messages, high or low god level, suspended and disabled.
+
  
|- style="background:lightgrey;"
+
So, test 0.2 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.503 (the canonical unavailable agent domain), the client library produces a "HTTP Service Not Available" exception.
| valign  ="top" width="10%" |
+
| valign="top" | '''fixture'''
+
| valign="top" | '''first name'''
+
| valign="top" | '''last name'''
+
| valign="top" | '''accepted TOS'''
+
| valign="top" | '''read critical messages'''
+
| valign="top" | '''god level'''
+
| valign="top" | '''suspended'''
+
| valign="top" | '''disabled'''
+
  
|- style="background:lightgrey;"
+
= LLSD Tests ( Test 1.* ) =
| valign="top" width="10%" |
+
| valign="top" width="12%" | 0.
+
| valign="top" width="11%" | Arthur
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
These tests exercise concepts introduced in the "LLSD" section of the OGP spec.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 1.
+
| valign="top" width="11%" | Bertha
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
== LLSD Test 1.0 - Return an Exception when Accessing a Resource with the Wrong HTTP Method ==
| valign="top" width="10%" |
+
| valign="top" width="12%" | 2.
+
| valign="top" width="11%" | Cristobal
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
If an agent domain, region domain or region receives a resource request using an unsupported HTTP method, the resource
| valign="top" width="10%" |
+
SHOULD respond with a HTTP 405 result code.
| valign="top" width="12%" | 3.
+
| valign="top" width="11%" | Dolly
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
Test 1.0 is considered "successful" if, after attempting sending a HTTP GET to the authentication URL defined in fixture 0.200 (a working agent domain), the client library produces a "LLSD Method Not Allowed" exception.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 4.
+
| valign="top" width="11%" | Edouard
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
== LLSD Test 1.1 - Return an Exception when Accessing a Resource via GET with an Improper Media Type in Accept ==
| valign="top" width="10%" |
+
| valign="top" width="12%" | 5.
+
| valign="top" width="11%" | Fay
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
If an agent domain, region domain or region receives a resource request via a HTTP GET, and the requester uses the 'Accept:' header to specify the media type it will accept, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 6.
+
| valign="top" width="11%" | Gustav
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
''hmm... need to define a canonical resource that accepts GET.''
| valign="top" width="10%" |
+
| valign="top" width="12%" | 7.
+
| valign="top" width="11%" | Hanna
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
== LLSD Test 1.2 - Return an Exception when Accessing a Resource via POST with an Improper Media Type in Accept Header ==
| valign="top" width="10%" |
+
| valign="top" width="12%" | 8.
+
| valign="top" width="11%" | Ana
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Accept:' header to specify the media type it will accept, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 9.
+
| valign="top" width="11%" | Bill
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
Test 1.2 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml' and the 'Accept:' header is set to 'application/llsd+foo', the client library produces a "LLSD Unsupported Media Type" exception.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 10.
+
| valign="top" width="11%" | Claudette
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
<pre>
| valign="top" width="10%" |
+
<?xml version="1.0"?>
| valign="top" width="12%" | 11.
+
<llsd>
| valign="top" width="11%" | Danny
+
  <key>agent_login</key>
| valign="top" width="11%" | Crimthande
+
  <map>
| align="center" valign="top" width="11%" | False
+
    <key>credential</key>
| align="center" valign="top" width="11%" | False
+
    <map>
| align="center" valign="top" width="11%" | 150
+
      <key>identifier</key>
| align="center" valign="top" width="11%" | False
+
      <map>
| align="center" valign="top" width="11%" | True
+
        <key>type</key>
 +
        <string>agent</string>
 +
        <key>first_name</key>
 +
        <string>Arthur</string>
 +
        <key>last_name</key>
 +
        <string>Crimthande</string>
 +
      </map>
 +
      <key>authenticator</key>
 +
      <map>
 +
        <key>type</key>
 +
        <string>hash</string>
 +
        <key>algorithm</key>
 +
        <string>md5</string>
 +
        <key>secret</key>
 +
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
 +
      </map>
 +
    </map>
 +
  </map>
 +
</llsd>
 +
</pre>
  
|- style="background:lightgrey;"
+
== LLSD Test 1.3 - Return an Exception when Accessing a Resource via POST with an Improper Media Type in Content-Type Header ==
| valign="top" width="10%" |
+
| valign="top" width="12%" | 12.
+
| valign="top" width="11%" | Erika
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Content-Type:' header to identify the media type of the the request body, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 13.
+
| valign="top" width="11%" | Fred
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
Test 1.3 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+foo', the client library produces a "LLSD Unsupported Media Type" exception.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 14.
+
| valign="top" width="11%" | Grace
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
  
|- style="background:lightgrey;"
+
<pre>
| valign="top" width="10%" |
+
<?xml version="1.0"?>
| valign="top" width="12%" | 15.
+
<llsd>
| valign="top" width="11%" | Henri
+
  <key>agent_login</key>
| valign="top" width="11%" | Crimthande
+
  <map>
| align="center" valign="top" width="11%" | False
+
    <key>credential</key>
| align="center" valign="top" width="11%" | False
+
    <map>
| align="center" valign="top" width="11%" | 0
+
      <key>identifier</key>
| align="center" valign="top" width="11%" | False
+
      <map>
| align="center" valign="top" width="11%" | True
+
        <key>type</key>
 +
        <string>agent</string>
 +
        <key>first_name</key>
 +
        <string>Arthur</string>
 +
        <key>last_name</key>
 +
        <string>Crimthande</string>
 +
      </map>
 +
      <key>authenticator</key>
 +
      <map>
 +
        <key>type</key>
 +
        <string>hash</string>
 +
        <key>algorithm</key>
 +
        <string>md5</string>
 +
        <key>secret</key>
 +
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
 +
      </map>
 +
    </map>
 +
  </map>
 +
</llsd>
 +
</pre>
  
|- style="background:lightgrey;"
+
== LLSD Test 1.4 - Return an Exception when POSTing bad XML to a Resource ==
| valign="top" width="10%" |
+
| valign="top" width="12%" | 16.
+
| valign="top" width="11%" | Alex
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
  
|- style="background:lightgrey;"
+
If an agent domain, region domain or region receives a resource request via a HTTP POST, and Content-Type header of the request describes the body of the request as being a 'application/llsd+xml' media type, and the body is improperly formed XML, the resource SHOULD respond with a HTTP 400 result code.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 17.
+
| valign="top" width="11%" | Bonnie
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
  
|- style="background:lightgrey;"
+
Test 1.4 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml', the client library produces a "LLSD Bad Request" exception.
| valign="top" width="10%" |
+
| valign="top" width="12%" | 18.
+
| valign="top" width="11%" | Colin
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 19.
+
| valign="top" width="11%" | Danielle
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 20.
+
| valign="top" width="11%" | Earl
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 21.
+
| valign="top" width="11%" | Fiona
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 22.
+
| valign="top" width="11%" | Gaston
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 23.
+
| valign="top" width="11%" | Hermine
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 24.
+
| valign="top" width="11%" | Arlene
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 25.
+
| valign="top" width="11%" | Bret
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 26.
+
| valign="top" width="11%" | Cindy
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 27.
+
| valign="top" width="11%" | Don
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 150
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 28.
+
| valign="top" width="11%" | Emily
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 29.
+
| valign="top" width="11%" | Franklin
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 30.
+
| valign="top" width="11%" | Gert
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | True
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="12%" | 31.
+
| valign="top" width="11%" | Harvey
+
| valign="top" width="11%" | Crimthande
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | 0
+
| align="center" valign="top" width="11%" | False
+
| align="center" valign="top" width="11%" | False
+
 
+
 
+
 
+
 
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| '''4. accounts'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9"| The SLGOGP specification describes the concept of an "account" as distinct from an "agent". Accounts may have distinct names and login credentials. Additionally, users may use the account credentials to authenticate themselves to the agent domain in the login process. At the current time, this functionality is not deployed to the Aditi grid.
+
 
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9" | '''5. faux machines'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="9" | These are used to test machines blacklisted by mac address or id0
+
 
+
|- style="background:lightgrey;"
+
| valign  ="top" width="10%" |
+
| valign="top" colspan="8" | 0. machine whose mac address and id0 are not blacklisted
+
|- style="background:lightgrey;"
+
| valign  ="top" width="10%" |
+
| valign="top" colspan="8" | 1.  machine whose mac address is blacklisted and id0 is not blacklisted
+
|- style="background:lightgrey;"
+
| valign  ="top" width="10%" |
+
| valign="top" colspan="8" | 2.  machine whose mac address is not blacklisted and id0 is blacklisted
+
|- style="background:lightgrey;"
+
| valign  ="top" width="10%" |
+
| valign="top" colspan="8" | 3.  machine whose mac address and id0 are blacklisted
+
 
+
== Transporting Fixtures ==
+
 
+
So it might not be the best idea to publish a standard list of usernames and passwords that are used for testing in live systems. We therefore expect the actual values for the test fixtures (or at least the passwords) to be confidential. To facilitate the exchange of known fixtures, we have the following XML DTD which defines the values of fixtures, so multiple parties can communicate test data easily.
+
 
+
'''note : the values of the test fixtures below are non-normative.''' Fixture data is loaded from an XML file and referenced in the tests by it's id attribute.
+
 
+
=== Fixture Transport DTD ===
+
  
 
<pre>
 
<pre>
<!DOCTYPE fixtures [
+
<?xml version="1.0"?>
 +
<llsd>
 +
  <key>agent_login</key>
 +
  <map
 +
    <key>credential</key>
 +
    <map>
 +
      <key>identifier</key>
 +
      <map>
 +
        <key>type</key>
 +
        <string>agent</string>
 +
        <key>first_name</key>
 +
        <string>Arthur</string>
 +
        <key>last_name</key>
 +
        <string>Crimthande</string>
 +
      </map>
 +
      <key>authenticator</key>
 +
      <map>
 +
        <key>type</key>
 +
        <string>hash</string>
 +
        <key>algorithm</key>
 +
        <string>md5</string>
 +
        <key>secret</key>
 +
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
 +
      </map>
 +
    </map>
 +
  </map>
 +
</llsd>
 +
</pre>
  
<!ELEMENT fixtures (agentdomains,regions,accounts,agents,urls,fauxmachines,id0blacklist,macblacklist)>
+
== LLSD Test 1.5 - Return an Exception when POSTing a misshaped request to a Resource ==
<!ELEMENT agentdomains (agent+)>
+
<!ELEMENT agent (#CDATA)>
+
<!ATTLIST agent id CDATA #REQUIRED>
+
<!ELEMENT regions (region+)>
+
<!ELEMENT region (host,port)>
+
<!ATTLIST region id CDATA #REQUIRED>
+
<!ELEMENT host (#CDATA)>
+
<!ELEMENT port (#CDATA)>
+
<!ELEMENT accounts (account+)>
+
<!ELEMENT account (name,password,agentrefs+)>
+
<!ATTLIST account id CDATA #REQURED>
+
<!ELEMENT name (#CDATA)>
+
<!ELEMENT password (#CDATA)>
+
<!ELEMENT agentrefs (agentref+)>
+
<!ELEMENT agentref (#EMPTY)>
+
<!ATTLIST agentref ref CDATA #REQUIRED>
+
<!ELEMENT agents (agent+)>
+
<!ELEMENT agent (firstname,lastname,password)>
+
<!ATTLIST agent id CDATA #REQUIRED>
+
<!ELEMENT firstname (#CDATA)>
+
<!ELEMENT lastname (#CDATA)>
+
<!ELEMENT password (#CDATA)>
+
<!ELEMENT urls (url+)>
+
<!ELEMENT url (#CDATA)>
+
<!ATTLIST url id CDATA #REQUIRED>
+
<!ELEMENT fauxmachines (fauxmachine+)>
+
<!ELEMENT fauxmachine (mac,id0)>
+
<!ATTLIST fauxmachine id CDATA #REQUIRED>
+
<!ELEMENT mac (#CDATA)>
+
<!ELEMENT id0 (#CDATA)>
+
<!ELEMENT id0blacklist (id0+)>
+
<!ELEMENT macblacklist (mac+)>
+
  
]>
+
If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Content-Type:' header to identify the media type of the the request body, and request is "mis-shaped" with respect to the LLIDL definition of the resource, it (the resource) SHOULD respond with a HTTP 400 result code.
</pre>
+
  
=== An Example of Fixture Data ===
+
Test 1.5 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml', the client library produces a "LLSD Bad Request" exception.
  
 
<pre>
 
<pre>
 
<?xml version="1.0"?>
 
<?xml version="1.0"?>
<fixtures>
+
<llsd>
   <agentdomains>
+
   <key>agent_login</key>
    <agent id="0_0">agent0.aditi.lindenlab.com</agent>
+
   <map>
    <agent id="0_1">agent1.aditi.lindenlab.com</agent>
+
     <key>identifier</key>
   </agentdomains>
+
     <string>agent</string>
  <regions>
+
     <region id="1_0">
+
      <host>sim1.vaak.secondlife.com</host>
+
      <port>13001</port>
+
     <region>
+
  </region>
+
  <accounts>
+
    <account id="2_0">
+
      <name>idontexist</name>
+
      <password>mekmitasdigoat</password>
+
      <agentrefs>
+
        <agentref ref="3_16"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_0">
+
      <name>Ana Goat</name>
+
      <password>Ahutrr</password>
+
      <agentrefs>
+
        <agentref ref="3_0"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_1">
+
      <name>Bill Goat</name>
+
      <password>Btehra</password>
+
      <agentrefs>
+
        <agentref ref="3_1"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_2">
+
      <name>Claudette Goat</name>
+
      <password>Carsobitl</password>
+
      <agentrefs>
+
        <agentref ref="3_2"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_3">
+
      <name>Danny Goat</name>
+
      <password>Dloly</password>
+
      <agentrefs>
+
        <agentref ref="3_3"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_4">
+
      <name>Erika Goat</name>
+
      <password>Eudroad</password>
+
      <agentrefs>
+
        <agentref ref="3_4"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_5">
+
      <name>Fred Goat</name>
+
      <password>Fay</password>
+
      <agentrefs>
+
        <agentref ref="3_5"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_6">
+
      <name>Grace Goat</name>
+
      <password>Gsutav</password>
+
      <agentrefs>
+
        <agentref ref="3_6"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_7">
+
      <name>Henri Goat</name>
+
      <password>Hnana</password>
+
      <agentrefs>
+
        <agentref ref="3_7"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_8">
+
      <name>Ida Goat</name>
+
      <password>Ike</password>
+
      <agentrefs>
+
        <agentref ref="3_8"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_9">
+
      <name>Joaquin Goat</name>
+
      <password>Jinpseohe</password>
+
      <agentrefs>
+
        <agentref ref="3_9"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_10">
+
      <name>Kate Goat</name>
+
      <password>Klye</password>
+
      <agentrefs>
+
        <agentref ref="3_10"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_11">
+
      <name>Larry Goat</name>
+
      <password>Lruaa</password>
+
      <agentrefs>
+
        <agentref ref="3_11"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_12">
+
      <name>Mindy Goat</name>
+
      <password>Mraco</password>
+
      <agentrefs>
+
        <agentref ref="3_12"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_13">
+
      <name>Nicholas Goat</name>
+
      <password>Nnaa</password>
+
      <agentrefs>
+
        <agentref ref="3_13"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_14">
+
      <name>Odette Goat</name>
+
      <password>Oamr</password>
+
      <agentrefs>
+
        <agentref ref="3_14"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_15">
+
      <name>Peter Goat</name>
+
      <password>Pamloa</password>
+
      <agentrefs>
+
        <agentref ref="3_15"/>
+
      </agentrefs>
+
    </account>
+
    <account id="3_16">
+
      <name>Rose Goat</name>
+
      <password>Rene</password>
+
      <agentrefs>
+
        <agentref ref="3_16"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_0">
+
      <name>Walter Llama</name>
+
      <password>Sally</password>
+
      <agentrefs>
+
        <agentref ref="6_0"/>
+
        <agentref ref="6_1"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_1">
+
      <name>Virginie Llama</name>
+
      <password>Tdedy</password>
+
      <agentrefs>
+
        <agentref ref="6_2"/>
+
        <agentref ref="6_3"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_2">
+
      <name>Thomas Llama</name>
+
      <password>Vkciy</password>
+
      <agentrefs>
+
        <agentref ref="6_4"/>
+
        <agentref ref="6_5"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_3">
+
      <name>Shary Llama</name>
+
      <password>Wlefird</password>
+
      <agentrefs>
+
        <agentref ref="6_6"/>
+
        <agentref ref="6_7"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_4">
+
      <name>Richard Llama</name>
+
      <password>Yvttee</password>
+
      <agentrefs>
+
        <agentref ref="6_8"/>
+
        <agentref ref="6_9"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_5">
+
      <name>Paula Llama</name>
+
      <password>zoomadsl</password>
+
      <agentrefs>
+
        <agentref ref="6_10"/>
+
        <agentref ref="6_11"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_6">
+
      <name>Otto Llama</name>
+
      <password>sesame</password>
+
      <agentrefs>
+
        <agentref ref="6_12"/>
+
        <agentref ref="6_13"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_7">
+
      <name>Nicole Llama</name>
+
      <password>password</password>
+
      <agentrefs>
+
        <agentref ref="6_14"/>
+
        <agentref ref="6_15"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_8">
+
      <name>Matthew Llama</name>
+
      <password>tiger</password>
+
      <agentrefs>
+
        <agentref ref="6_16"/>
+
        <agentref ref="6_17"/>
+
      </agentrefs>
+
    </account>
+
    <account id="5_9">
+
      <name>Lisa Llama</name>
+
      <password>toor</password>
+
      <agentrefs>
+
        <agentref ref="6_18"/>
+
        <agentref ref="6_19"/>
+
      </agentrefs>
+
    </account>
+
  </accounts>
+
  <agents>
+
    <agent id="4_0">
+
      <firstname>Arlene</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>smcadmin</password>
+
    </agent>
+
    <agent id="4_1">
+
      <firstname>Bret</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>SKY_FOX</password>
+
    </agent>
+
    <agent id="4_2">
+
      <firstname>Cindy</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>changeme</password>
+
    </agent>
+
    <agent id="4_3">
+
      <firstname>Don</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>piranha</password>
+
    </agent>
+
    <agent id="4_4">
+
      <firstname>Emily</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>zoomadsl</password>
+
    </agent>
+
    <agent id="4_5">
+
      <firstname>Franklin</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>sesame</password>
+
    </agent>
+
    <agent id="4_6">
+
      <firstname>Gert</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>password</password>
+
    </agent>
+
    <agent id="4_7">
+
      <firstname>Harvey</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>tiger</password>
+
    </agent>
+
    <agent id="4_8">
+
      <firstname>Irene</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>toor</password>
+
    </agent>
+
    <agent id="4_9">
+
      <firstname>Jose</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>admin</password>
+
    </agent>
+
    <agent id="4_10">
+
      <firstname>Katia</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>smcadmin</password>
+
    </agent>
+
    <agent id="4_11">
+
      <firstname>Lee</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>SKY_FOX</password>
+
    </agent>
+
    <agent id="4_12">
+
      <firstname>Maria</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>changeme</password>
+
    </agent>
+
    <agent id="4_13">
+
      <firstname>Nate</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>piranha</password>
+
    </agent>
+
    <agent id="4_14">
+
      <firstname>Ophelia</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>zoomadsl</password>
+
    </agent>
+
    <agent id="4_15">
+
      <firstname>Philippe</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>sesame</password>
+
    </agent>
+
    <agent id="4_16">
+
      <firstname>Rina</firstname>
+
      <lastname>Sheep</lastname>
+
      <password>password</password>
+
    </agent>
+
    <agent id="6_0">
+
      <firstname>William</firstname>
+
      <lastname>Camel</lastname>
+
      <password>tiger</password>
+
    </agent>
+
    <agent id="6_1">
+
      <firstname>Valerie</firstname>
+
      <lastname>Camel</lastname>
+
      <password>toor</password>
+
    </agent>
+
    <agent id="6_2">
+
      <firstname>Tony</firstname>
+
      <lastname>Camel</lastname>
+
      <password>admin</password>
+
    </agent>
+
    <agent id="6_3">
+
      <firstname>Sandy</firstname>
+
      <lastname>Camel</lastname>
+
      <password>smcadmin</password>
+
    </agent>
+
    <agent id="6_4">
+
      <firstname>Rafael</firstname>
+
      <lastname>Camel</lastname>
+
      <password>SKY_FOX</password>
+
    </agent>
+
    <agent id="6_5">
+
      <firstname>Patty</firstname>
+
      <lastname>Camel</lastname>
+
      <password>changeme</password>
+
    </agent>
+
    <agent id="6_6">
+
      <firstname>Oscar</firstname>
+
      <lastname>Camel</lastname>
+
      <password>piranha</password>
+
    </agent>
+
    <agent id="6_7">
+
      <firstname>Nadine</firstname>
+
      <lastname>Camel</lastname>
+
      <password>zoomadsl</password>
+
    </agent>
+
    <agent id="6_8">
+
      <firstname>Michael</firstname>
+
      <lastname>Camel</lastname>
+
      <password>sesame</password>
+
    </agent>
+
    <agent id="6_9">
+
      <firstname>Leslie</firstname>
+
      <lastname>Camel</lastname>
+
      <password>password</password>
+
    </agent>
+
    <agent id="6_10">
+
      <firstname>Kirk</firstname>
+
      <lastname>Camel</lastname>
+
      <password>tiger</password>
+
    </agent>
+
    <agent id="6_11">
+
      <firstname>Joyce</firstname>
+
      <lastname>Camel</lastname>
+
      <password>toor</password>
+
    </agent>
+
    <agent id="6_12">
+
      <firstname>Isaac</firstname>
+
      <lastname>Camel</lastname>
+
      <password>admin</password>
+
    </agent>
+
    <agent id="6_13">
+
      <firstname>Helene</firstname>
+
      <lastname>Camel</lastname>
+
      <password>smcadmin</password>
+
    </agent>
+
    <agent id="6_14">
+
      <firstname>Gordon</firstname>
+
      <lastname>Camel</lastname>
+
      <password>SKY_FOX</password>
+
    </agent>
+
    <agent id="6_15">
+
      <firstname>Florence</firstname>
+
      <lastname>Camel</lastname>
+
      <password>changeme</password>
+
    </agent>
+
    <agent id="6_16">
+
      <firstname>Ernesto</firstname>
+
      <lastname>Camel</lastname>
+
      <password>ntacdmax</password>
+
    </agent>
+
    <agent id="6_17">
+
      <firstname>Debby</firstname>
+
      <lastname>Camel</lastname>
+
      <password>pento</password>
+
    </agent>
+
    <agent id="6_18">
+
      <firstname>Chris</firstname>
+
      <lastname>Camel</lastname>
+
      <password>microbusiness</password>
+
    </agent>
+
    <agent id="6_19">
+
      <firstname>Beryl</firstname>
+
      <lastname>Camel</lastname>
+
      <password>johnlee</password>
+
    </agent>
+
    <agent id="6_20">
+
      <firstname>Alberto</firstname>
+
      <lastname>Camel</lastname>
+
      <password>piranha</password>
+
    </agent>
+
  </agents>
+
  <urls>
+
    <url id="8_0">http://agent0.aditi.lindenlab.com/messages/notice.html</url>
+
  </urls>
+
  <fauxmachines>
+
    <fauxmachine id="9_0">
+
      <mac>01:80:C2:00:00:00</mac>
+
      <id0>3fPkIs1eG0doeDj8uscIZQ==</id0>
+
    </fauxmachine>
+
    <fauxmachine id="9_0">
+
      <mac>01:80:C2:00:00:01</mac>
+
      <id0>3fPkIs1eG0doeDj8uscIZQ==</id0>
+
    </fauxmachine>
+
    <fauxmachine id="9_0">
+
      <mac>01:80:C2:00:00:00</mac>
+
      <id0>4EahsGwT/GYg9uBSQeKcNA==</id0>
+
    </fauxmachine>
+
    <fauxmachine id="9_0">
+
      <mac>01:80:C2:00:00:01</mac>
+
      <id0>4EahsGwT/GYg9uBSQeKcNA==</id0>
+
    </fauxmachine>
+
  </fauxmachines>
+
  <id0blacklist>
+
    <id0 id="10_0">4EahsGwT/GYg9uBSQeKcNA==</id0>
+
  </id0blacklist>
+
  <macblaclist>
+
    <mac id="11_0">01:80:C2:00:00:01</mac>
+
  </macblacklist>
+
</fixtures>
+
  
</pre>
+
    <key>first_name</key>
 +
    <string>Arthur</string>
  
= Base Tests =
+
    <key>last_name</key>
 +
    <string>Crimthande</string>
  
== REST Tests ==
+
    <key>authenticator</key>
 +
    <string>hash</string>
  
== LLSD (Linden Lab Structured Data) ==
+
    <key>algorithm</key>
 +
    <string>md5</string>
  
== Event Queue ==
+
    <key>secret</key>
 
+
    <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
== Capabilities ==
+
  </map>
 +
</llsd>
 +
</pre>
  
= Resource Tests =
 
  
== Agent Credential ==
+
= Authentication Tests ( Test 2.* ) =
  
== Account Credential ==
+
== Authentication Test 2.0 - Successful Authentication of an Agent Identifier and a Hashed Authenticator ==
  
= Login Tests =
+
Test 2.0 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the agent defined in fixture 1.0 (Arthur Crimthande) using a 'hash' type authenticator and an 'agent' type identifier, a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).
  
Login is the process of associating a viewer with an agent domain, then placing the user's avatar in a region managed by a (potentially separate) region domain. The spec describes logging in as the sequence:
+
== Authentication Test 2.1 - Unsuccessful Authentication of an Agent Identifier and a Hashed Authenticator ==
  
# The viewer authenticates to an agent domain for the authorized control of a particular agent.
+
Test 2.1 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the agent defined in fixture 1.1 (Bertha Crimthande) using a 'hash' type authenticator and an 'agent' type identifier, a 'key' condition response is returned with the salt, count and duration items undefined.
# The viewer directs the agent domain to to place the agent in a region.
+
# The agent domain contacts the region domain for the region, and negotiates placement of the agent.
+
# The region grants access to the agent domain, which in turn passes some of that granted access on to the viewer.
+
  
Testing the login process means logging each of these steps, in order. We should also test that executing them out of order leads to an error.
 
  
We assume the code providing underlying services (such as the event queue, LLSD serialization / deserialization, MD5 Hash production, etc.) is reliable and has been tested.
+
== Authentication Test 2.2 - Successful Authentication of an Account Identifier with a Single Agent and a Hashed Authenticator ==
  
== Tests From Client to Agent Domain ==
+
Test 2.2 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.0 (cristobal@example.com) using a 'hash' type authenticator and an 'account' type identifier, a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).
  
{|style="background:white" width="100%" cellpadding="5"
+
== Authentication Test 2.3 - Unsuccessful Authentication of an Account Identifier with a Single Agent and a Hashed Authenticator ==
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''0. test agent authentication'''
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| This test suite tests the behavior of the agent domain when an agent attempts to log in with correct authenticators, and with the "accept_tos" and "read_critical_messages" flags set to True. In these tests, we assume the user is attempting authentication from a machine that has not been blacklisted by MAC address or id0. Note that the agent fixtures used below (4.0 through 4.3) have different states regarding "accept_tos" and "read_critical_messages" on the agent domain. This suite tests that authentication works and the agent domain will accept "accept_tos" and "read_critical_messages" changes.
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" | 0. authenticate agent in fixture 4.0 with correct authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
  
|- style="background:lightgrey;"
+
Test 2.3 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.1 (dolly@example.com) using a 'hash' type authenticator and an 'account' type identifier, a 'key' condition response is returned with the salt, count and duration items undefined.
| valign="top" width="10%" |
+
| valign="top" colspan="2" | 1. authenticate agent in fixture 4.1 with correct authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
  
|- style="background:lightgrey;"
+
== Authentication Test 2.4 - Successful Authentication of an Account Identifier with a Multiple Agents with the Selected Agent in the Request and a Hashed Authenticator ==
| valign="top" width="10%" |
+
| valign="top" colspan="2" | 2. authenticate agent in fixture 4.2 with correct authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
  
|- style="background:lightgrey;"
+
Test 2.4 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.2 (edouard@example.com) using a 'hash' type authenticator and an 'account' type identifier, with the agent defined in fixture 1.4 (Edouard Crimthande) a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).
| valign="top" width="10%" |
+
| valign="top" colspan="2" | 3. authenticate agent in fixture 4.3 with correct authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
  
|- style="background:lightgrey;"
+
== Authentication Test 2.5 - Unsuccessful Authentication of an Account Identifier with a Multiple Agents with the Selected Agent in the Request and a Hashed Authenticator ==
| valign="top" colspan="3"| '''1. test failures in agent authentication'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. authenticate agents in fixtures 4.[0-3] with incorrect authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''2. test account authentication'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. authenticate accounts in fixtures 3.[0-3] with correct authenticator
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |1. authenticate accounts in fixture 5.0 with one of of the agent names from fixture 6.0 or 6.1
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''3. test non-existent agent'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixture 3.4
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "notice" with url fixture 8.0
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''4. test non-existent account'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixture 2.0
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "notice" with url fixture 8.0
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''5. test non-existing agent in existent account'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixture 3.4 and name from 2.0
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "notice" with url fixture 8.0
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''6. test existing account with no agent specified in account with one agent'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixtures 3.[0...3] with no name specified
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect seed cap
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''7. test existing account with no agent specified in account with multiple agents'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixtures 5.[0...9] with no name specified
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "select_agent"
+
|- style="background:lightgrey;"
+
| valign="top" colspan="3"| '''8. test existing account which has been blacklisted'''
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |0. attempt to authenticate with fixture 4.0 and faux machine 9.1
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "blacklisted"
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |1. attempt to authenticate with fixture 4.0 and faux machine 9.2
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "blacklisted"
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" colspan="2" |2. attempt to authenticate with fixture 4.0 and faux machine 9.3
+
|- style="background:lightgrey;"
+
| valign="top" width="10%" |
+
| valign="top" width="10%" |
+
| valign="top" | expect reason "blacklisted"
+
|}
+
  
= Teleport Tests =
+
Test 2.5 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.3 (gustav@example.com) using a 'hash' type authenticator and an 'account' type identifier, with the agent defined in fixture 1.6 (Gustav Crimthande) a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).
  
 +
== Authentication Test 2.6 - Select Failure of an Account Identifier with a Multiple Agents and a Hashed Authenticator ==
  
 +
Test 2.6 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.4 (ana@example.com) using a 'hash' type authenticator and an 'account' type identifier, without an agent selected in the response, a 'select' condition response is returned with the 'agents' list set to: [ 'Ana', 'Crimthande', 'Bil', 'Crimthande' ].
  
 
[[Category: Pyogp]]
 
[[Category: Pyogp]]
 
[[Category:Pyogp_Kitchen_Sink]]
 
[[Category:Pyogp_Kitchen_Sink]]
 +
[[Category:AW Groupies]]
 +
[[Category:Grid Interoperability]]
 +
[[Category:AW Groupies User Pages]]

Latest revision as of 15:44, 18 January 2009

  • note: this is a brief note for informational purposes. it's eventually going to be "cleaned up" and moved to a more appropriate place on this wiki.
  • note: this is a branch from the original "OGP" Test Case page. PyOGP Test Cases are defined at User:Saijanai_Kuhn/OGP_Test_Cases

Contents

Introduction

What is This?

In the development of the Open Grid Protocol and the PyOGP project, it became obvious that there were no canonical lists of use cases and things to test. This page is the first effort to remediate this omission. While we don't go as far as providing use cases here, we do list common functionality and interoperability tests.

About the OGP Test Cases

The objective of the Open Grid Protocol is to specify syntax and semantics of SL Grid messages to the degree that interoperable viewers, agent domains, region domains and regions may be coded without resort to close examination of open source code from Linden Lab or peeking into the interaction between running clients and servers. The Second Life Grid has been developed sufficiently, the reasoning goes, that it should be possible to shine the bright light of inquiry on the process and document the living heck out of how the system works. Moving forward we should see advantages as software developers code to documented requirements and standards. The "OGP Test Cases" are a catalog of tests that demonstrate compatibility with the written spec.

Well... that's how it's supposed to be... In the real world, "running code" trumps written specifications, and probably will continue to do so. And that's one of the reasons we have the interop tests; properly written test cases succinctly communicate abstractions introduced in written specifications. So rather than viewing the SLGOGP spec and these tests as separate, think of them as being two sections of the same document.

Base Tests ( Test 0.* )

Many OGP messages take the form of an LLSD message serialized to XML and POSTed to an URL somewhere via HTTP (or HTTPS.) In the ideal world, HTTP would be free from error. But as it turns out there are many ways in which a HTTP request could fail, especially if your implementation of OGP uses proxies, load balancers, n-tier service architectures, etc. These tests are intended to ensure your client library properly communicates HTTP errors, assuming your client library has a standard technique for handling and recovering from such errors.

It is entirely possible that your client library does not handle such errors cleanly. This is not a failure, per se, but we strongly encourage implementers to expose an interface to client applications allowing exceptional events to be communicated through the client library and to the application.

Base Test 0.0 - Return an Exception when Accessing a Non-Existent Resource

This test simply posts a properly formatted login request to an URL that does not exist. We anticipate a HTTP 404 result code, or at least that's what we would return if you sent a request to an undefined URL. In an ideal world we would test a resource from each resource class to ensure client library code handling each message properly propagates the "Not Found" exception. However, in the interests of alacrity we're only describing this test in terms of the agent_login resource class.

So, test 0.0 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.404 (the canonical undefined agent domain), the client library produces a "HTTP Not Found" exception.

Base Test 0.1 - Return an Exception when Accessing a "Broken" Resource

This test posts a properly formatted login request to an URL that has been preconfigured to return a HTTP 500 result code.

So, test 0.1 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.500 (the canonical broken agent domain), the client library produces a "HTTP Internal Server Error" exception.

Base Test 0.2 - Return an Exception when Accessing an "Unavailable" Resource

This test posts a properly formatted login request to an URL that has been preconfigured to return a HTTP 503 result code.

So, test 0.2 is considered "successful" if after attempting to access the agent_login resource defined for fixture 1.0 (Arthur Crimthande) at the agent domain described in fixture 0.503 (the canonical unavailable agent domain), the client library produces a "HTTP Service Not Available" exception.

LLSD Tests ( Test 1.* )

These tests exercise concepts introduced in the "LLSD" section of the OGP spec.

LLSD Test 1.0 - Return an Exception when Accessing a Resource with the Wrong HTTP Method

If an agent domain, region domain or region receives a resource request using an unsupported HTTP method, the resource SHOULD respond with a HTTP 405 result code.

Test 1.0 is considered "successful" if, after attempting sending a HTTP GET to the authentication URL defined in fixture 0.200 (a working agent domain), the client library produces a "LLSD Method Not Allowed" exception.

LLSD Test 1.1 - Return an Exception when Accessing a Resource via GET with an Improper Media Type in Accept

If an agent domain, region domain or region receives a resource request via a HTTP GET, and the requester uses the 'Accept:' header to specify the media type it will accept, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.

hmm... need to define a canonical resource that accepts GET.

LLSD Test 1.2 - Return an Exception when Accessing a Resource via POST with an Improper Media Type in Accept Header

If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Accept:' header to specify the media type it will accept, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.

Test 1.2 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml' and the 'Accept:' header is set to 'application/llsd+foo', the client library produces a "LLSD Unsupported Media Type" exception.

<?xml version="1.0"?>
<llsd>
  <key>agent_login</key>
  <map>
    <key>credential</key>
    <map>
      <key>identifier</key>
      <map>
        <key>type</key>
        <string>agent</string>
        <key>first_name</key>
        <string>Arthur</string>
        <key>last_name</key>
        <string>Crimthande</string>
      </map>
      <key>authenticator</key>
      <map>
        <key>type</key>
        <string>hash</string>
        <key>algorithm</key>
        <string>md5</string>
        <key>secret</key>
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
      </map>
    </map>
  </map>
</llsd>

LLSD Test 1.3 - Return an Exception when Accessing a Resource via POST with an Improper Media Type in Content-Type Header

If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Content-Type:' header to identify the media type of the the request body, and that media type is not supported by the resource, the resource SHOULD respond with a HTTP 415 result code.

Test 1.3 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+foo', the client library produces a "LLSD Unsupported Media Type" exception.

<?xml version="1.0"?>
<llsd>
  <key>agent_login</key>
  <map>
    <key>credential</key>
    <map>
      <key>identifier</key>
      <map>
        <key>type</key>
        <string>agent</string>
        <key>first_name</key>
        <string>Arthur</string>
        <key>last_name</key>
        <string>Crimthande</string>
      </map>
      <key>authenticator</key>
      <map>
        <key>type</key>
        <string>hash</string>
        <key>algorithm</key>
        <string>md5</string>
        <key>secret</key>
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
      </map>
    </map>
  </map>
</llsd>

LLSD Test 1.4 - Return an Exception when POSTing bad XML to a Resource

If an agent domain, region domain or region receives a resource request via a HTTP POST, and Content-Type header of the request describes the body of the request as being a 'application/llsd+xml' media type, and the body is improperly formed XML, the resource SHOULD respond with a HTTP 400 result code.

Test 1.4 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml', the client library produces a "LLSD Bad Request" exception.

<?xml version="1.0"?>
<llsd>
  <key>agent_login</key>
  <map
    <key>credential</key>
    <map>
      <key>identifier</key>
      <map>
        <key>type</key>
        <string>agent</string>
        <key>first_name</key>
        <string>Arthur</string>
        <key>last_name</key>
        <string>Crimthande</string>
      </map>
      <key>authenticator</key>
      <map>
        <key>type</key>
        <string>hash</string>
        <key>algorithm</key>
        <string>md5</string>
        <key>secret</key>
        <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
      </map>
    </map>
  </map>
</llsd>

LLSD Test 1.5 - Return an Exception when POSTing a misshaped request to a Resource

If an agent domain, region domain or region receives a resource request via a HTTP POST, and the requester uses the 'Content-Type:' header to identify the media type of the the request body, and request is "mis-shaped" with respect to the LLIDL definition of the resource, it (the resource) SHOULD respond with a HTTP 400 result code.

Test 1.5 is considered "successful" if, after POSTing the following message body to the authentication URL defined in fixture 0.200 (a working agent domain) with the 'Content-Type:' header set to 'application/llsd+xml', the client library produces a "LLSD Bad Request" exception.

<?xml version="1.0"?>
<llsd>
  <key>agent_login</key>
  <map>
    <key>identifier</key>
    <string>agent</string>

    <key>first_name</key>
    <string>Arthur</string>

    <key>last_name</key>
    <string>Crimthande</string>

    <key>authenticator</key>
    <string>hash</string>

    <key>algorithm</key>
    <string>md5</string>

    <key>secret</key>
    <binary encoding="base16">c169c172e7a5dafc74f69c476c0a4869</binary>
  </map>
</llsd>


Authentication Tests ( Test 2.* )

Authentication Test 2.0 - Successful Authentication of an Agent Identifier and a Hashed Authenticator

Test 2.0 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the agent defined in fixture 1.0 (Arthur Crimthande) using a 'hash' type authenticator and an 'agent' type identifier, a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).

Authentication Test 2.1 - Unsuccessful Authentication of an Agent Identifier and a Hashed Authenticator

Test 2.1 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the agent defined in fixture 1.1 (Bertha Crimthande) using a 'hash' type authenticator and an 'agent' type identifier, a 'key' condition response is returned with the salt, count and duration items undefined.


Authentication Test 2.2 - Successful Authentication of an Account Identifier with a Single Agent and a Hashed Authenticator

Test 2.2 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.0 (cristobal@example.com) using a 'hash' type authenticator and an 'account' type identifier, a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).

Authentication Test 2.3 - Unsuccessful Authentication of an Account Identifier with a Single Agent and a Hashed Authenticator

Test 2.3 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.1 (dolly@example.com) using a 'hash' type authenticator and an 'account' type identifier, a 'key' condition response is returned with the salt, count and duration items undefined.

Authentication Test 2.4 - Successful Authentication of an Account Identifier with a Multiple Agents with the Selected Agent in the Request and a Hashed Authenticator

Test 2.4 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.2 (edouard@example.com) using a 'hash' type authenticator and an 'account' type identifier, with the agent defined in fixture 1.4 (Edouard Crimthande) a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).

Authentication Test 2.5 - Unsuccessful Authentication of an Account Identifier with a Multiple Agents with the Selected Agent in the Request and a Hashed Authenticator

Test 2.5 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.3 (gustav@example.com) using a 'hash' type authenticator and an 'account' type identifier, with the agent defined in fixture 1.6 (Gustav Crimthande) a 'success' condition response is returned and the agent_seed_capability URI is subordinate to the seed root defined in fixture 0.200 (a working agent domain).

Authentication Test 2.6 - Select Failure of an Account Identifier with a Multiple Agents and a Hashed Authenticator

Test 2.6 is considered "successful" if after requesting the agent_login resource defined in fixture 0.200 (a working agent domain) with the account defined in fixture 2.4 (ana@example.com) using a 'hash' type authenticator and an 'account' type identifier, without an agent selected in the response, a 'select' condition response is returned with the 'agents' list set to: [ 'Ana', 'Crimthande', 'Bil', 'Crimthande' ].