Re: [Evolution-hackers] Rethinking account management



On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
> It would be good to allow also username changing in EPasswords. It's
> very unusual to allow only password entering when most applications are
> allowing to change both username and password (I'm not aware of any
> other with "enter password only" functionality at the moment). It seems
> to be related, a bit, thus I'm bringing it here.
> 
> Also note one thing which might require a bit rewriting. If I recall
> correctly you would use the ESource's UID for password storing. The
> thing is that evolution allows setting "auth-method", which is used as
> 'component'. The advantage of this is that the ESource for calendar can
> share password from mailer (while not knowing the parent source/account
> at all), because they are using same 'component' and 'key'. So with your
> change in the passwords there should be a knowledge to which account is
> this ESource tight (which is not always clear right now?), and this
> "parent" account should be used instead of the actual ESource, right?

User name and authentication method will be stored in a key file group,
which defines the following keys (from my notes):

Schema: org.gnome.Evolution.Source.Authentication
------------------------------------------------------------------------------
[extensions/authentication]
------------------------------------------------------------------------------
domain                  : 's'	(do we still need this?)
method			: 's'	('none' means auth not required)
remember-password	: 'b'
user			: 's'

Both the user name and authentication method can be changed freely.

For a groupware account that shares authentication details across all
data sources, it would make sense to put the authentication group in the
top-level ESource alongside account details, then have child ESources
for mail accounts, calendars, etc. refer to it.  The keyring entry for
the groupware account would store the UID of the top-level ESource so
the password too can be easily be shared across all data sources.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]