http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #19 from yongsheng zhu <[email protected]> 2009-09-06 19:57:44 --- (In reply to comment #18) > (In reply to comment #16) > > current probable passwords I can imagine: > > 1)SyncML server account and password: > > auxiliary information: server name, user name > > 2)Proxy Password: > > auxiliary information: server name, user name > > 3)Passwords possibly in backend: > > currently possible evolution password, auxiliary information: user name > > 4)Connection related password: > > such as bluetooth connection authentication, auxiliary information: > > possibly > > device name > > Let me rephrase my question: with which keys would you store each of these > passwords in the GNOME keyring? The keys have to be unique enough so that > different passwords don't end up having the same key. At the same time the > keys > should not be too specific, because then irrelevant differences (http vs > https) > force reentering the password. I understand it. The auxiliary information I list is the key I consider suitable and enough for saving password in keyring. They maybe not accurate, but as the first step. For the parameter list for 'askPassword' and 'savePassword', I'd like to use the parameter list of keys in the gnome network password . Some of them might be empty but there are reasons to use them: 1) It can cover almost all the scenarios no matter what passwords might be in users' new backend implementations 2) Since it is from gnome-keyring parameter list, it is enough to store passwords in the keyring. 3) Let ConfigUserInterface's implemenators decide which information they'll use to store passwords. See below: askPassword(string& descr, string& passwordName, string& user, string& domain,string& server,string& object,string& protocol,string& authtype,unsigned int port) savePassword(string& descr, string& passwordName, string& password, string& user, string& domain,string& server,string& object,string& protocol,string& authtype,unsigned int port) passwordName is the name in the config file for the password, such as 'password', 'proxyPassword'. This is for 'UserInterface' to decide which password it will save. I think these names should be unique. user, domain, server, etc are used as keys of keyring. I list them to consider all scenarios currently in which passwords may be used > > 1)SyncML server account and password: > > auxiliary information: server name, user name syncML server: syncML server plus user is enough > > 2)Proxy Password: > > auxiliary information: server name, user name The key should be server name(should plus port and protocol), user name > > 3)Passwords possibly in backend: > > currently possible evolution password, auxiliary information: user name I think for evolution, the key 'user name' is enough. Since user may use new passwords, it is uncertain. > > 4)Connection related password: > > such as bluetooth connection authentication, auxiliary information: > > possibly device name > How do the functions decide which keys they are to use? The "descr" string > might be used in askPassword(), but then we have to document which description > is used for which password. savePassword() doesn't have something like this, > making it unsuitable for use with more than just the main account password. PasswordName is the purpose for this. > (In reply to comment #17) > > current I leave parameters of 'askPassword' and 'savePassword' unchanged > > except > > 'ConfigNode'. > > Which one would be passed if these functions are called for source passwords? > Always the one for the SyncClientConfig properties? The code doesn't document > this. Also > > Patrick, could you check my branch again? > > Much better, but I think the handling of all passwords should be implemented > before merging it. I think it should be the handling design issues for all passwords. Not actually implementation, right? -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
