[sldev] RFC: design proposal for VWR-1071
Melinda Green
melinda at superliminal.com
Tue Jul 14 12:48:16 PDT 2009
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.
More information about the SLDev
mailing list