http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #20 from pohly <[email protected]> 2009-09-08 01:56:02 --- (In reply to comment #19) > (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. I stumbled over point 3, "user name" as sole key. That's not enough, because completely different Evolution backends (Exchange calendar, Groupwise user list) would have to share a single entry in the keyring. Properly identifying which Evolution backends can have the same password is hard, therefore I suggest to err on the side of caution and use server name, source name, and a fixed string "Backend" (for object) as GNOME keyring keys. When I say "server name" and "source name", I mean the names as used in the SyncEvolution config ("scheduleworld" + "addressbook", for example). In your list above, did you mean server and proxy URL? That would be consistent with the current way of storing the SyncML server password. > 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. [...] > 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. Yes, this looks like a better approach, compared to granting access to the config and forcing the UI create these keys from the config. The long list of parameters is a bit ugly. Normally I'd suggest to put them into a struct, which could be extended without changing the API, which would allow extending it without having to change UIs. Except in this case UIs *have* to be changed when we add a new key: if the key is used, then the UI must not ignore it. Normally I prefer to make API changes in such a way that old code doesn't even compile, which is an argument in favor of the long parameter list. This doesn't work here, because we have a default implementation of these virtual methods and old code with the old function signature simply won't be called. Therefore I prefer the struct approach after all. Thoughts? > > 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? The implementation would be nice, too. We got away in the sync-ui with incomplete password support because it is meant to be used in situations where only one password is needed, but the command line as the fallback for the other situations should better be complete. There's another issue here: properties can be added by backends dynamically. Therefore the list of passwords that the UI's savePassword() is called for shouldn't be fixed. For askPassword() this is handled by reading all properties, which triggers askPassword(). We should do something similar for savePassword() and call it "preFlush()", or something like that, because it might be used for other checks besides storing passwords in a keyring. -- 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
