http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #21 from yongsheng zhu <[email protected]> 2009-09-08 05:03:15 --- > 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. Reasonable. Got it. > 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. For (2), the proxy password, 'server name' refers to 'proxy URL' and 'user name' refers to 'proxy user name'. This password should not be related to 'syncML server name'. > > 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. > [...] somewhat confusing. I mean using gnome keyring as a reference to define parameter list. > > 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? Good, I also like this idea. Besides, I'd like to add some padding fields for future expansion to avoid re-compile if needing a new field in the future. > > > 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. Ok, I'll do this. > 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. Yes, this is similar to the reason why I overridding the flush function: just want to do something before actually doing flush. Currently we invoke 'savePassword' before flushing. Instead, a virtual new added function is used to invoke 'savePassword' or something else before flushing. I'll add this function. -- 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
