[sldev] RFC: design proposal for VWR-1071

[Melinda Green]

Cypren,

I like your approach to this popular problem, especially your intention 
to save full first-last-password triplets which I feel makes the feature 
valuable. As a first contribution you're taking on a fair bit of risk 
lot due to the usability issues involved, but seeing how popular the 
issue is, I'm pulling for you. Just be aware that the non-obvious GUI 
design issues make this one decidedly not "simple" and that the biggest 
potential pitfalls will not be technical ones.

I think that your idea of using a drop-down for the first name field 
that contains both first and last names is clever. It makes for yet 
another non-standard UI element which is to be avoided when standard 
options are practical but I don't see an obvious standard alternative. I 
therefore encourage you to try it out and see what people think. The 
Snowglobe project is the perfect place to try out these sorts of things.

One aspect of your design which needs some thought is how to get entries 
*off* the list once they've been added. (Also note that only entries 
that resulted in successful logins should ever be added.) Here's one 
possible solution: You can let the "remember password" checkbox control 
which triplets get saved. Unchecking the box for any entry should 
immediately remove any previously saved data for that entry but leave 
the text fields intact. That solves the most important case of saving 
all three fields but will make some people unhappy if they want to save 
only a first+last name pair and require passwords to be entered each 
time. I would strongly suggest not designing solutions with more UI 
complexity than this simply to try to make those people happy. Maybe 
someone else can suggest a simple solution that would make everyone 
happy but if not, this might make for a reasonable compromise.

-Melinda

Cypren Christenson wrote:
> Hello everyone. I've been following the list for a while and finally
> decided to get my hands dirty and contribute to the codebase. I've
> picked out a seemingly very simple feature add to start with, and
> wanted to post my proposed solution so that wiser, more experienced
> heads could possibly caution me about any pitfalls that I may be
> rushing into, given my inexperience with the project.
>
> VWR-1071 (http://jira.secondlife.com/browse/VWR-1071) is a fairly
> simple request: add a method for users with multiple SL
> accounts/identities to store their credentials and quickly pick
> between them at the login screen, instead of only having the last
> login credentials saved. Since there are multiple text input fields on
> the login screen, my inclination is to change the First Name field to
> a combo box rather than a text box, and display both a first and last
> name in the dropdown list. Selecting an entry from this list would
> then populate all three fields (or only the name fields if password
> saving is not enabled). The list would simply hold a history of all
> logins made by that user account on that computer.
>
> >From my initial examination of the relevant code (LLPanelLogin), it
> seems like this can be solved by editing the XUI (panel_login.xml) and
> then altering the fields stored and retrieved from gSavedSettings.
> Since there does not appear to be an object serialization storage
> method for gSavedSettings, I'm inclined to store a double-tokenized
> string in a form such as:
>
>   John|Doe|<md5 passsword>/Fred|Doe|/Jane|Doe|<md5 password>
>
> The "higher" token delimiter (the slash character, in that example)
> breaks apart each record, and the "lower" token delimiter (the pipe)
> breaks apart the three fields in the record. An empty password field
> would indicate that a user did not check "save password". Tokenization
> would be done using boost::tokenizer.
>
> The potential pitfalls I see with this approach:
>
> * Login history strings could potentially become very long. Are there
> practical limits to how long of a string the LLControlGroup class can
> store?
> * The use of a combo box for the first field, with selection setting
> the contents of multiple fields, may be confusing. Any other options
> here that would be more intuitive while also keeping the aesthetic
> sensibility of the existing login screen would be welcome.
> * Possible security concerns with the characters selected for the
> delimiters. With LLPanel::childSetPrevalidate to filter characters
> from input, the worst-case scenario seems to be that a malicious user
> could edit settings files and induce boost::tokenizer to fail to parse
> the string correctly. In that event, we would simply clear the
> relevant fields. Are there other concerns I'm missing?
>
> Any answers to these questions, or general suggestions or comments are
> most welcome.