|
|
| (3 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| Pyogp will be implementing and testing many of the Legacy and OGP protocols. This is a listing of those protocols as well as the details on how to go about implementing and testing them.
| | #REDIRECT [[PyOGP]] |
| | |
| Note that for the exception fields for the calls in each step, you can generally get all the standard exceptions for HTTP, sockets, or URLs. However, the ones listed are the ones that are typical signs that something may be off.
| |
| =Login=
| |
| ==Legacy Login==
| |
| We will detail what needs to be done to login with the legacy protocols.
| |
| | |
| ==OGP Login==
| |
| *[[OGP_Draft_Login|OGP Draft Login flowchart]] - flowchart for current OGP login protocols
| |
| *[[SLGOGP_Teleport_Strawman]] - flowchart for teleport, which is essentially login as well
| |
| Login is the process of establishing the three way communication between viewer, agent and region. There are two phases, viewer to agent login, and then placement of agent in a particular region. Over the course of a viewer session, the agent may move around from region to region, and so constitutes a repetition of the agent to region login phase.
| |
| | |
| The OGP uses HTTP methods for logging in, such as POST and GET.
| |
| | |
| ===Flow Outline===
| |
| #Login to auth.cgi on a login server with credentials
| |
| #Get other capabilities, such as place_avatar
| |
| #Post to place_avatar with desired region_url | |
| | |
| ===Details===
| |
| The first thing that needs to be done is to pass our credentials to a login server that is running the OGP protocols (agent domain implemented). Currently, Linden Lab has a server that is running an agent domain that is still a work-in-progress. The login server is https://login1.aditi.lindenlab.com/cgi-bin/auth.cgi.
| |
| | |
| <b>Step 1 - Login to login server running OGP protocols (has agent domain implemented) to get agent host seed capability</b>
| |
| | |
| {| border="1"
| |
| |-
| |
| |
| |
| Verb
| |
| |
| |
| POST
| |
| |-
| |
| |
| |
| URL
| |
| |
| |
| login url for the agent domain<br>
| |
| https://login1.aditi.lindenlab.com/cgi-bin/auth.cgi
| |
| |-
| |
| |
| |
| Headers
| |
| |
| |
| {"Content-type" : "application/llsd+xml"}
| |
| |-
| |
| |
| |
| Request
| |
| |
| |
| {"password": ''password'',<br>
| |
| "lastname": ''lastname'',<br>
| |
| "firstname": ''firstname''}
| |
| |-
| |
| |
| |
| Response - Success
| |
| |
| |
| agent-host-seed-capability url<br>
| |
| Note: in the current LL implementation of the agent domain, there is redirect that needs to take place. When posting to the login url, there will be a HTTP 302 error that will have the capability url set in the 'location' field of the error headers (headers['location']). You will have to properly handle the exception thrown in order to get the location of the redirect.
| |
| |-
| |
| |
| |
| Response - Failure
| |
| |
| |
| *HTTP 404 - Not Found - your credentials were probably typed in incorrectly, your agent isn't registered, or something else.
| |
| |-
| |
| |
| |
| Exceptions
| |
| |
| |
| *HTTP 500 - Internal Server Error - the login server is down. Someone must internally fix it.
| |
| |}
| |
| <br>
| |
| | |
| <b>Step 2 - Getting Capabilities (at least place_avatar)</b>
| |
| Step 1 got us the agent-host-seed-capability. With the seed capability we can invoke it and get other capabilities for anything that we might need to do. At the very least, we should be getting the place_avatar capability because we need this to get placed onto a region (or simulator). We may also want the event_queue capability, among others.
| |
| | |
| {| border="1"
| |
| |-
| |
| |
| |
| Verb
| |
| |
| |
| POST
| |
| |-
| |
| |
| |
| URL
| |
| |
| |
| agent-host-seed-capability from Step 1
| |
| |-
| |
| |
| |
| Headers
| |
| |
| |
| {"Content-type" : "application/llsd+xml"}
| |
| |-
| |
| |
| |
| Request
| |
| |
| |
| { "caps": [ ''name1'', ''name2'', … ] }
| |
| |-
| |
| |
| |
| Response - Success
| |
| |
| |
| { "caps": { ''name1'': url1, ''name2'': url2, … } }
| |
| |-
| |
| |
| |
| Response - Failure
| |
| |
| |
| |-
| |
| |
| |
| Exceptions
| |
| |
| |
| |}
| |
| <br>
| |
| <b>Step 3 - invoking place_avatar</b>
| |
| Step 2 got us the url for the place_avatar capability. Now we have to invoke it with the region url of where we want to be placed. This invocation causes us to be placed in the region (or on a simulator). The response also gives us the capability to the region/sim (called "seed_capability" in the response), along with the ip, port, and everything else we need to connect to the sim. With the seed capability for the sim, we can start communicating with it.
| |
| | |
| {| border="1"
| |
| |-
| |
| |
| |
| Verb
| |
| |
| |
| POST
| |
| |-
| |
| |
| |
| URL
| |
| |
| |
| place_avatar capability from Step 2
| |
| |-
| |
| |
| |
| Headers
| |
| |
| |
| {"Content-type" : "application/llsd+xml"}
| |
| |-
| |
| |
| |
| Request
| |
| |
| |
| {"region_url": <url string><br>
| |
| "position": [<f32>''x'', <f32>''y'', <f32>''z'']}<br><br>
| |
| Note: position is optional
| |
| |-
| |
| |
| |
| Response - Success
| |
| |
| |
| {<br>
| |
| "seed_capability": <uri string><br>
| |
| "look_at" : [<f32>''x'', <f32>''y'', <f32>''z'']<br>
| |
| "sim_ip": <ip string><br>
| |
| "sim_port": <int><br>
| |
| "region_x": <int><br>
| |
| "region_y": <int><br>
| |
| "region_id" : <uuid><br>
| |
| "sim_access" : <string> "PG"|"Mature"<br>
| |
| "connect": <bool><br>
| |
| "position": [<f32>''x'', <f32>''y'', <f32>''z'']<br>
| |
| // Extra stuff<br>
| |
| "connect": <bool><br>
| |
| // The above are the same as response to rez_avatar<br>
| |
| // The following are only returned on login, not over teleport<br>
| |
| "session_id":<uuid><br>
| |
| "secure_session_id":<uuid><br>
| |
| "circuit_code":<int><br>
| |
| }
| |
| |-
| |
| |
| |
| Response - Failure
| |
| |
| |
| *HTTP 400 - Bad Requeset - Seems we get a 400 when we try to log in too soon after logging out.
| |
| |-
| |
| |
| |
| Exceptions
| |
| |
| |
| *Sometimes the circuit_code, session_id, or secure_session_id aren't returned. This is probably when the region or sim believes we are already logged in (didn't log out the last time we exited)
| |
| |
| |
| |}
| |
| <br>
| |
| <b>Step 4 - LOGIN COMPLETE</b>
| |
| Now we can start communicating with the sim using the information we received as a response from Step 3. From here, we go into different protocols to follow. We have to establish presence, set up the event_queue, and start getting and sending updates to the sim.
| |
| | |
| =Presence=
| |
| After we get logged on, we must establish and maintain presence. This takes some work to do.
| |
| ==What is presence?==
| |
| Placeholder
| |
| ==How to establish presence==
| |
| Placeholder
| |