Re: [Evolution-hackers] Authentication/Password Issue in Evolution Data Server .....

[Jeffrey Stedfast <fejj ximian com>]

There will still be times when the backend has to query the front-end
for a password (ie. if it doesn't have one cached and/or the one cached
was bad).

This means that evolution proper will still have to query for passwords
and that is 90% of the issue. At that point, why not just have the
front-end save them?

Besides... the mailer is going to have to have the save logic anyway,
might as well share it among all the components.

Jeff

On Wed, 2004-03-10 at 15:19, Chris Toshok wrote:
> The authentication support in the addressbook is kind of sticky, yes.
> 
> The main issue that brought about the current architecture is that the
> user might configure evolution to authenticate to an ldap server that
> might otherwise not require it.  LDAP servers exist (in fact I
> administer one) that work for both anonymous and authenticated access. 
> They typically just prune the set of attributes/entries they show to
> unauthenticated clients.
> 
> Given that we didn't want to be adding username/password to the uris we
> were sending the wombat back in the 1.x days, this meant the UI had to
> be the one that authenticated.  Also, it lead to some icky interactions
> when the UI calls a corba method in the wombat, then the wombat calls a
> corba method on the UI to pop up the password dialog... this was a
> recipe for blocking in the old architecture, and both UI and wombat
> would deadlock.  Making it async made things even more complicated. 
> This should be much more easily solved with the new e-d-s code.
> 
> The thing about requiring authentication once-per-uri as opposed to once
> per client already holds, since e-d-s hashes backends by their uri, and
> all clients that load the same uri share the same backend.  That is,
> once one client authenticates, they are all authenticated.
> 
> I agree that e-d-s should be the place where passwords are managed, but
> that requires idl changes, libebook api changes and some rearchitecting.
> 
> Chris
> 
> On Wed, 2004-03-10 at 04:49, Amit Shrivastava wrote:
> > Hi,
> > 
> > I am using evolution-data-server API to get addressbooks data for OO.o,
> > so at the backend it uses ldap server, groupwise servr etc based on the
> > URI. 
> > 
> > For authenticating to the backend server like ( ldap server, groupwise
> > server etc ), it is required to provide password for each of the server
> > and manage these passwords in the client, "evolution" also
> > caches/manages these passwords , similarly each of the client have to do
> > password some management. Which is not a good thing. 
> > 
> > It should be such that once a client ( either evolution ) provides the
> > password it should be cached by the eds server and managed subsequently
> > and the client should'nt care about the backend authentication. I hope
> > we can avoid even first time password something like iLogin, once I
> > login in my desktop i dont need to provide password for any applications
> > :-).
> > 
> > It will be good option that the passwords for the backends are managed
> > by evolution-data-server, and client just need to tell other
> > configuration parameters, and never meddle with the passwords.
> > 
> > 
> > regards,
> > Amit 
> > _______________________________________________
> > evolution-hackers maillist  -  evolution-hackers lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-hackers
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
>