GNOME Bugzilla – Bug 686804
GOA integration for Google Calendar
Last modified: 2013-07-10 06:56:04 UTC
EDS uses CalDAV to access Google Calendar and OAuth tokens don't work with Google's CalDAV endpoint. This causes a "enter your password" dialog to be thrown at the user when they create a new GOA Google account. Maybe it makes sense to disable the GOA integration for calendars? Or consider using libgdata?
I think password-based auth for CalDAV is better than nothing at all. Using GData would require someone writing and maintaining a whole new vendor-specific E-D-S backend. Philip Withnall wrote and somewhat maintains the GData-based address book backend, but I don't know if he has the time or interest to write a calendar backend.
Here's the issue as I see it: Someone sets up a Google account in GOA; they enter their username and password, and the account is setup correctly. Then, after a pause, they get a system modal dialog asking them to re-enter their password. This is a surprise. It also seems broken (they've just entered their password: why are they being asked for it again?) We simply can't throw up a system modal password dialog at this stage. It breaks the experience, and it's really unwelcome.
Perhaps GOA should ask for a password up front if the Google Calendar switch is enabled until we have a better solution for this (or until Google supports OAuth for CalDAV).
We can always steal the password from the embedded web browser, put it into the keyring and offer a PasswordBased interface (alongwith the existing OAuth2Based) interface for a Google account. What I am worried about is whether this violates some Google ToS or not. We are already fiddling with the DOM of those web pages for polishing the UX, so maybe we can play some more. If they suddenly change the web page behind our back, we will fallback to the "ask the user for her passwd" behaviour.
I'm surprised you can do that, but yeah some sort of best-effort action would be a useful stopgap. I could patch E-D-S to start checking for a PasswordBased interface on Google Calendars immediately if that's the plan.
(In reply to comment #2) > Here's the issue as I see it: > > Someone sets up a Google account in GOA; they enter their username and > password, and the account is setup correctly. Then, after a pause, they get a > system modal dialog asking them to re-enter their password. This is a surprise. > It also seems broken (they've just entered their password: why are they being > asked for it again?) > > We simply can't throw up a system modal password dialog at this stage. It > breaks the experience, and it's really unwelcome. Moreover, if you are using the 2-step authentication, I doubt you'll remember the generated password at all and will endup seeing this dialog popping-up forever.. At least thats whats happening on my machine.
(In reply to comment #6) > Moreover, if you are using the 2-step authentication, I doubt you'll remember > the generated password at all and will endup seeing this dialog popping-up > forever.. At least thats whats happening on my machine. We don't have an answer for those using 2-factor authentication, unless EDS grows a libgdata backend for calendars.
(In reply to comment #7) > (In reply to comment #6) > > Moreover, if you are using the 2-step authentication, I doubt you'll remember > > the generated password at all and will endup seeing this dialog popping-up > > forever.. At least thats whats happening on my machine. > > We don't have an answer for those using 2-factor authentication, unless EDS > grows a libgdata backend for calendars. No, I'm not asking for that *yet*. :) You can generate a password for apps where you can't use 2-step authentication. The generated password is nothing you can remember (unless you have a photographic memory). I keep it around in a gpg encryped file. When needed, I decrypt it and C&P it. In this case the dialog doesn't let me do anything but either enter the password or dismiss the dialog.
*** Bug 687539 has been marked as a duplicate of this bug. ***
I'm not sure what this bug is about, it diverged from initial "disable Google CalDAV when it cannot use OAuth" to "system modal password prompts are wrong". It'll be good to change the bug summary accordingly. From my point of view: - Google doesn't support OAuth on CalDAV - nothing we can do about that - not offering CalDAV-based Google calendar in eds is currently impossible - there used to be a libgdata-based calendar backend in the past, but it was so bad that using standard CalDAV worked much better, thus the libgdata calendar backend had been dropped - since 3.6.x evolution uses gcr for password prompts, which are system modal, which kinda sucks for various reasons (as mentioned on multiple sources by different people). There probably can be done something about that, but not on time for 3.8.x - it's too late for such change, isn't it? I do not know gcr, maybe they allow non-system modal password prompts? In any way, 3.8.x will use libsecret, not gcr directly. Matthew knows all about this point.
(In reply to comment #10) > I'm not sure what this bug is about, it diverged from initial "disable Google > CalDAV when it cannot use OAuth" to "system modal password prompts are wrong". > It'll be good to change the bug summary accordingly. It is about improving the Google Calendar integration in GNOME via GOA. "disable CalDAV when it cannot use OAuth" and "system modal password prompts are wrong" are basically symptoms of the same problem. Since we don't use OAuth2 to authenticate to Google Calendars, EDS used to throw those black system modal dialogs at us, which is bad. We hacked around this by screen scraping the user's raw password from the web browser in GOA and offering it to EDS. However, that does not work for users using Google's 2-factor authentication [1]. This 2-factor authentication is getting more and more popular and raw passwords do not work when a user has enabled it. One either has to use OAuth2 or use a so-called "app-specific password" generated by Google. As mentioned in comment #6, most users can't remember these generated passwords and having a system modal stops them from copy-pasting it from an encrypted file. As far as I understand it, currently their GData API is the only option. In future they will support OAuth2 over Google Calendars, but that API is still experimental and not available for the public. However we do have (including mbarnes) access to it for testing. [1] http://www.google.com/landing/2step/
Is there anything we can do here for 3.8 ?
Last week Google publicly announced their new CalDAV API which requires OAuth2, as compared to their old one which did not work with OAuth2. This means that all Google accounts (including ones with 2-factor) should now work with Google Calendars via CalDAV. Obviously this would be fixed for 3.10, but given the importance of this bug we could try to backport it for 3.8.1 or 3.8.2. I had a brief chat with Milan about the required changes in EDS to handle it and he thinks we can do that. As far as GOA is concerned we would need to revert the following patch which should be ok to do in a 3.8.x release: commit 89c335479c1bb8409af8296c99ffea602a28b71f Author: Debarshi Ray <debarshir@gnome.org> Date: Sun Nov 4 21:29:22 2012 +0100 google: Offer a PasswordBased interface We are not sure when, or if at all, Google will support OAuth2 for CalDAV. Instead of spoiling the user experience by asking for the password again, lets offer applications a way to fetch it without bothering the user. Fixes: https://bugzilla.gnome.org/687578
ok, thats some hope, at least.
Any update on this? The CalDAV API is available again.
Google got rid of its whitelist for using CalDAV over OAuth2: http://googledevelopers.blogspot.com.au/2013/06/making-googles-caldav-and-carddav-apis.html I have turned on the bits for using CalDAV over OAuth2 in Google's API Console, and bumped the credentials generation in GOA's master. Now it is over to EDS to implement the new CalDAV API over OAuth2.
Thanks rishi, I'll try and squeeze some time in for this soon.
Just added Google CalDAV v2 support for Evolution-Data-Server 3.9.5. https://git.gnome.org/browse/evolution-data-server/commit/?id=13afda757c4ba8d558eaa64853849f2ad00a9806 E-D-S will automatically use the OAuth 2.0 based CalDAV v2 interface for new and existing Google accounts configured through GNOME Online Accounts or Ubuntu Online Accounts. Google calendars added directly through Evolution will continue using the password-based CalDAV v1 interface for as long as Google keeps it working. Closing as FIXED.
Will this change be ported to F19?
Thanks!