No subject
Fri Jun 12 11:19:36 PDT 2009
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