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

[Argent Stonecutter]

On 2007-12-20, at 13:19, Donovan Preston wrote:
> 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.

That's what I thought, but Tess was talking about "parsing" it out,  
which isn't quite how I'd describe reading the "Location:" header.

>>> 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.

I thought of 401 but it says "The response MUST include a WWW- 
Authenticate header field (section 14.47) containing a challenge  
applicable to the requested resource".

You could use 404, but that should really be restricted to missing data.

You could be cheeky and use 402, but that's reserved even though it's  
vaguely appropriate.

I think that "Authorization will not help and the request SHOULD NOT  
be repeated" refers to HTTP authorization using WWW-Authenticate.  
That is, if the server is implementing authentication outside the  
HTTP authentication mechanism (for example, with a login form) then  
it certainly doesn't want the browser popping up a WWW authentication  
dialog, so it should return 403 to tell the browser that it can't use  
that mechanism.

There really isn't another code than 403 that could be used here, and  
403 is what I've seen from most servers (except for the ones that  
don't bother to implement any 4xx other than 404... and some servers  
don't even return 404, they always return redirects to annoyingly  
uninformative help files).

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

That's what I was thinking of this case being for. :)

>> 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.

That's what I thought.

> 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.

I thought about that, but that means that if you just got the  
password wrong you'd have to open a browser window. I considered  
that, too, but it's not really good user interface design. If you  
typo the account name and password you should just get a message  
saying the login failed so you can correct it and try again. For  
unattended clients, too, it's useful to distinguish a bad account/ 
password (likely a configuration error) from something that needs  
immediate human attention.

That doesn't mean you can't trigger a redirect if the user's tried 20  
different passwords in the last minute and you want to let them know  
the account's locked out.

Now I think about it, for interactive clients, the user interface can  
handle that case. Just a slight change:

>> 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.


The message would be displayed, and instead of using the llLoadURL  
dialog you'd just put a "(More Information)" button next to the  
message... clicking that would follow the redirect.