|
|
| (12 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]] |
| | |
| =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
| |
| 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.
| |
| | |
| ===Step 1 - Login to login server running OGP protocols (has agent domain implemented) to get agent host seed capability===
| |
| | |
| {| 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
| |
| |
| |
| |-
| |
| |
| |
| Exceptions
| |
| |
| |
| *HTTP 500 - Internal Server Error - the login server is down. Someone must internally fix it.
| |
| |}
| |
| <br>
| |
| ===Step 2 - Getting Capabilities (at least place_avatar)===
| |
| 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
| |
| |
| |
| |}
| |