[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