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 - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
