Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Fri, 2015-02-27 at 20:14 +0900, Tristan Van Berkom wrote: [0]: A note on semantics of opening a client, we really should be deprecating the DRA specific semantics in favor of making DRA the default and just falling back on pure DBus in the case where DRA is unavailable, this was the original plan, and would make for one less 'technique' of opening the client, which is really just API bloat at this point, anyway. Which back ends still don't support DRA? I fixed EWS but at that time ISTR there were still some which weren't supporting it. I'd quite like to merge evolution-pkcs11 at some point... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
I havent been active in EDS for some time so feel free to take my comments with an appropriate grain of salt... On Fri, 2015-02-27 at 11:09 +0100, Patrick Ohly wrote: On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote: On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote: What I would prefer instead of the additional int parameter is a string-variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. Hi, I would not do that this way. It would be horrible to call the function and create extra arguments for it in some sort of array and variants and so on. It's a pita to convert parameters forth and back when passing them through GDBus already, thus rather not add the same burden to the client functions too. I'm not convinced, but it's your project. However, I reserve the right to say told you so once the API needs to be changed the next time. Changing API is always a delicate dance, I have to agree that creating a less convenient API in anticipation of future changes is not a desirable way forward. Hopefully most of these semantics need not be changed in terms of 'ways to open the client'[0]. It's also hard to imagine many justifications for requiring more arguments to e_book_client_connect(), we do have the ESourceExtensions and the backend properties which are very flexible already. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. I always understood that it's the soname version which is meant to cover these situations. Not that the two versions of eds can be installed in parallel in one prefix. But distro's typically don't do that because it's extra work to maintain two versions of the same software in parallel. It also would not work for EDS, because each client library is typically tightly coupled with a certain daemon version, and those cannot be installed or run in parallel. This tight coupling between sonames and EDS daemon does not strictly have to be the case, however I would like to echo Patrick's concerns with a word of caution against incrementing the soname of the user facing libraries. It's one thing to bump the sonames of the backend related libraries (libedata-book, libedata-cal and everything backend related), as all this means is that any third party backend providers need to relink against the new API and ensure everything works. It's quite another thing to break the user facing libebook and libecal API, as it means: o Any frontend users of EDS need to relink and ensure their EDS based applications still work o For applications which just work and opt out of the extra work involved in linking the new libebook/libecal, these would no longer benefit from bugfixes made in the new EDS API. o As an alternative to the previous, this may in fact add an extra maintenance burden, should bug fixes really need to be backported to previous versions with different sonames. I.e. telling someone to upgrade the EDS libraries on an older system is no longer valid on it's own, as applications are not linking the same soname yet. Just saying, breaking API in the user facing libraries is not something to take lightly, bumping the soname in these libraries should really be a last resort. Best Regards, -Tristan [0]: A note on semantics of opening a client, we really should be deprecating the DRA specific semantics in favor of making DRA the default and just falling back on pure DBus in the case where DRA is unavailable, this was the original plan, and would make for one less 'technique' of opening the client, which is really just API bloat at this point, anyway. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote: On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote: What I would prefer instead of the additional int parameter is a string-variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. Hi, I would not do that this way. It would be horrible to call the function and create extra arguments for it in some sort of array and variants and so on. It's a pita to convert parameters forth and back when passing them through GDBus already, thus rather not add the same burden to the client functions too. I'm not convinced, but it's your project. However, I reserve the right to say told you so once the API needs to be changed the next time. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. I always understood that it's the soname version which is meant to cover these situations. Not that the two versions of eds can be installed in parallel in one prefix. But distro's typically don't do that because it's extra work to maintain two versions of the same software in parallel. It also would not work for EDS, because each client library is typically tightly coupled with a certain daemon version, and those cannot be installed or run in parallel. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote: Hello, I just committed a change, for 3.13.90 development version, into evolution-data-server [1], evolution [2], evolution-ews [3] and evolution-mapi [4], which moves authentication back to the clients. As discussed with Milan on IRC, I was worried that this change would break compatibility with SyncEvolution although SyncEvolution primarily (exclusively?!) is used with local storage, which works without authentication. I now looked further and found that SyncEvolution already works with the new EDS, despite the changed API (e_book_client_connect, e_cal_client_connect). That's because SyncEvolution opens an ESource with e_client_open(), which hasn't changed. SyncEvolution obviously won't work for sources which require authentication, but I don't think that'll be a big issue. [...] I have not looked at the concept in detail, but it looks reasonable at first glance. The other follow-up work will be to adapt any clients and libraries which might be affected by this change. I'd like to help as much as I'll be able, thus if there will be any issues spotted, feel free to ping me or drop me an email and I'll help you to migrate your code. I also removed all the old authentication code and functions, to avoid those system-modal prompts and basically all the old behavior users didn't like, the same as to cleanup API as much as possible. Bye, Milan [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=884fb8d872787d9 One comment that I already made on IRC: adding one additional int parameter to e_book_client_connect and e_cal_client_connect falls a bit short IMHO. I bet there will be some point in the future when some other new parameter will also be needed, causing another API break which could be avoided now. What I would prefer instead of the additional int parameter is a string-variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote: The other follow-up work will be to adapt any clients and libraries which might be affected by this change. Hi, I've only a little note, I wrote proposed changes for gnome-contacts to enable client-side authentication in it at [1]. A similar change can be used in any client which wants to answer authentication requests. As the gnome-contacts uses only address books, then the authentication requests are enabled only for them and their parent (credential) sources (search for E_SOURCE_EXTENSION_ADDRESS_BOOK in the patch), all the other sources' authentication requests are ignored. I hope this will make things easier for others. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=743979#c0 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Move authentication of backends back to the client (3.13.90)
Hello, I just committed a change, for 3.13.90 development version, into evolution-data-server [1], evolution [2], evolution-ews [3] and evolution-mapi [4], which moves authentication back to the clients. That is, any credentials (password) prompts are done fully asynchronously on the backend side, and the clients are responsible to provide the credentials. There is one exception, if the credentials are already saved, then they are used first, without any communication between the backend and the clients. This is done in a very similar way as it used to be couple years ago, except the notifications about credentials requests and authentications responses are handled on top of ESource objects. I chose the ESource object, because it already manages password saving and because some backends, those on the source registry side, cannot be accessed in any different way. There is also a proxy in EBackend, which works on top of the ESource methods and signals, making things easier for the backend implementators. The backend proxy also makes couple things for free, based on the existence of certain ESource extensions, which are updated accordingly during the authentication process. The extensions are E_SOURCE_EXTENSION_AUTHENTICATION and E_SOURCE_EXTENSION_WEBDAV_BACKEND. The first is updated when the received credentials contain also user name, the second is updated with a trust prompt results, which are also passed into the backend as part of the credentials. That's required, because the change on the ESource can be propagated to backends too late, due to the round-trip from the client to evolution-source-registry, and only then to the factory, while the client talks to the factory directly. The backend open and the authentication process currently looks like: client-side| D-Bus |backend-side --- e_client_open() | | ECal/BookBackend::open() is called: | | a) either set ESource::connection-status to CONNECTED | | b) or try to connect to the server without credentials | |and use e_backend_credentials_required/_sync() or | | e_backend_schedule_credentials_required() to broadcast | |a request for credentials to any client listening | | listener of ESource::credentials-requ | | ired signal can ask for actual| | credentials a user and send them back | | with e_source_invoke_authenticate() | | | | implement EBackendClass::authenticate_sync() to receive | | and use the provided credentials. Based on the result | | of this function is updated ESource::connection-status | | automatically and the output arguments are used to | | iterate with e_backend_credentials_required() again | | The main differences from the pre-this-change behaviour are: a) the backend can open without being connected to the destination (possibly remote) data store b) the ESource::credentials-required signal is delivered to all current listeners of evolution-source-registry, not only to the one which requested the open of the backend c) the backend works with the new ESource::connection-status in its open() implementation only, as long as it uses the provided proxy functions on the EBackend master class. As mentioned above, the credentials-required reasons also contain an SSL failures (aka when the destination server certificate checking fails for some reason), which allows to tight the Trust Prompts to the clients as well, thus they are not shown out of blue in the system anymore. I re-introduces libedataserverui library, which holds structures to handle credential prompts and show the trust prompts directly in the application's UI. The library is built conditionally, only when the GTK+ is available. The easiest way to implement credential prompt in an application is to create an ECredentialsPrompter and let it live for a whole time of the application. It listens for ESource::credentials-required signal and responds only to REQUIRED and REJECTED reasons. There can be disabled this auto-prompt, either globally or for respective sources. This credential prompter also listens for ESource::connection-status changes and cancels any ongoing prompts when it changes. That's one of the reasons why the
