[sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues

Dr Scofield hud at zurich.ibm.com
Thu Jan 10 00:24:10 PST 2008


Sean Dague wrote:
> On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote:
>   
>> the new web based authentication scheme uses a web page to capture the 
>> fullname and the password of an avatar and returns a web_login_key that is 
>> passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL 
>> client takes that secondlife:///app/login/... URI and extracts the 
>> web_login_key (and first and last name and other stuff it seems) and goes 
>> to the login service to log the avatar/agent in to the grid.
>>
>> while this works with the LL grid, it does not work with OpenSim grids, 
>> because the LL SL client has no clue that it needs to go to a different, 
>> non-LL grid login service: the latest release clients and the windlight 
>> client do provide the -loginpage which would allow us to direct the client 
>> to a login page of our own, where we could then generate the 
>> secondlife:///app/login/.. URI --- however, that URI does not include any 
>> reference whatsoever to the grid you want to connect to (well, it does to 
>> some extent: there is a 'grid' parameter but that only knows about LL grids 
>> and also does not include ports, resources, etc)
>>
>> teravus ousley has described this in much more detail (and probably better 
>> than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he 
>> also tried several other things (have a look at VWR-4021, if you are 
>> interested in the details) to no avail: we cannot get the latest windlight 
>> and RC clients to connect to OpenSim grids/servers.
>>
>> luckily, we had a chance to discuss this with tess linden at yesterday's 
>> AWGroupies meeting. the following two proposals came up:
>>
>>    (a) use the currently empty host part of the secondlife:///app/login
>>    URI to specify the grid server: that is, to connect to my 4x4
>>    OpenSim grid running here in the lab, i'd have the following URI:
>>
>>        
>> secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=....
>>
>>    the LL SL client would simply do a s/^secondlife:/http:/
>>    substitution and use the resulting URL to login the avatar in.
>>
>>    (b) recast the currently used grid parameter to always contain the
>>    FQDN of the grid server along with port and resource; that is, for
>>    my lab grid that would be:
>>
>>        
>> secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=....
>>
>>    here the client would have to parse the URI, extract the grid
>>    parameter, un-quote its value, then construct the login URL and
>>    login the avatar in.
>>
>> clearly, approach (a) seems to be the cleanest approach and fits well with 
>> the common URI scheme. however...
>>
>> ...during the discussion it transpired that the reason the host part of the 
>> secondlife:/// URI is empty, is that the target of that SLURL is *not* the 
>> grid server but the *client*! in particular, /app/login signals to the 
>> client what it should do: login via a URL that it needs to construct from 
>> the supplied URI.
>>
>> ...also, as fword utorid remarked, using the secondlife: URI to trigger a 
>> grid login adds a new semantic to the secondlife: URI --- so far it has 
>> been used as a kind of secondlife GPS location fix: 
>> secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 
>> island, for example. now, secondlife:///app/login?... addresses the 
>> secondlife client and tells it to do a login to a grid.
>>     
>
> I (aka neas bade) will continue to express frustration on this design
> point.  I know that secondlife:/// URI-like-things are currently used as
> a hack to get a webbrowser to trigger an external application, however I
> think that sticking with that design point causes confusion as well as
> leads to the implicit hardcoding of the main grid into the client.
>
> secondlife://osgrid.org:8002/app/login equaly conveys to the client what it
> should do, that is connect to a network resource for login.  If we have
> append the web_login_key= to this request, we can fully process that URI
> back to the server as a well understood resource on the network,
> returning to us any appropriate further information needed.
>
> secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit
> hostname is in this URI scheme.  That really should be
> secondlife://secondlife.com/IBM%206/127/104/88, which would let you load
> SLURLs for other grids in a sensible way (and you'd get appropriately
> prompted for credentials in the equiv of HTTP AUTH domains).
>   
i completely agree...the question is can we get this to work given that 
we already have a few of those secondlife://Bla%20bla%20/127/104/88 URIs 
around? it might work as long as you don't have island names that are 
valid FQDN...

    dr scofield

-- 
dr dirk husemann, pervasive computing, ibm zurich research lab
--- hud at zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/ad37192a/attachment.htm


More information about the SLDev mailing list