[sldev] Re: [VWR] Web login without llmozlib

Donovan Preston donovan at lindenlab.com
Thu Dec 20 11:19:07 PST 2007


On Dec 19, 2007, at 12:25 PM, Argent Stonecutter wrote:

> That pretty much *is* the web-service API I was referring to. The  
> only difference is that I suggested that a successful response  
> should be a redirect to the "secondlife:" URI described in the  
> original announcement. That allows the normal HTTP response codes to  
> do the rest of the job.

I'm confused by this. Currently, a successful response from the go.php  
service *is* a redirect to the "secondlife:" URI.

I am going to attempt to add llsd content type encoding for the input  
to go.php today (instead of multipart/mime it currently accepts from  
the embedded browser). This will reduce the number of protocols  
required to log in and make it easier for viewers built without  
llmozlib to log in without knowing how to generate multipart/mime.

However, what is the llsd-supporting version of go.php to do when  
authentication does not succeed? I think you're on the right track,  
comments below.

>> The tricky part here is what to do when login fails.
>
> That's covered in the response codes. HTTP is designed for this  
> situation.
>
> Successful login:
>    303 Success-message-for-user
>    Location: secondlife:...
>    Other-headers...
>
>    -- no body ---
>
> Authentication failure:
>    403 Failure-message-for-user
>    Headers...
>
>    HTML error message

403 is "Forbidden", and the rfc says the client shouldn't *ever*  
bother trying again, cause it ain't gonna work. So I don't think this  
is what we want.

> Server failure:
>    5xx Message-for-user
>    Headers...
>
>    HTML error message

This would only be used if the server choked and died.

> Special handling:
>    307 Message-for-user
>    Location: URL requesting more information
>    Other-headers...
>
>    --- no body ---

I think one of the redirects is right. 307 is probably right because  
it's not cacheable. In practice it doesn't matter since POST isn't  
cacheable anyway. So I think the heuristic should be:

Successful login, redirect to secondlife: URI.
Additional information required, redirect to https: URL.

> The viewer doesn't require any new complex code. No matter what the  
> response is, it contains a message to display to the user. If a web  
> page display is required, it contains a redirect to that page. The  
> client can display that in llMozLib or redirect to an external  
> browser. It can even use the existing framework for llLoadURL to  
> give the user a dialog approving that redirect.

Sounds great.

Donovan


More information about the SLDev mailing list