RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1229377 - Evolution asks for password for GOA Calendar with OAuth2
Summary: Evolution asks for password for GOA Calendar with OAuth2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: evolution-data-server
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Milan Crha
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-08 14:55 UTC by Jiri Koten
Modified: 2015-11-19 07:59 UTC (History)
2 users (show)

Fixed In Version: evolution-data-server-3.12.11-23
Doc Type: Bug Fix
Doc Text:
Cause: unneeded password prompt for CalDAV calendars configured in GOA using OAUth2 authentication Consequence: sometimes was incorrectly detected that certain GOA configured calendar has OAuth2 authentication and it was asked for password, which shouldn't be done with OAuth2 Fix: correct the detection of OAuth2 authentication method being used Result: password is not required, the connection to the server fails with an error instead
Clone Of:
Environment:
Last Closed: 2015-11-19 07:59:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
debug eds patch (3.27 KB, patch)
2015-06-08 17:15 UTC, Milan Crha 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2226 0 normal SHIPPED_LIVE evolution bug fix and enhancement update 2015-11-19 08:37:43 UTC

Description Jiri Koten 2015-06-08 14:55:53 UTC 
Description of problem:
I have Google calendars added through GOA using OAuth2 for authentication. From time to time, evolution fails to authenticate and shows password prompt for one of the calendars. This shouldn't happen for calendars using OAuth2. 

Restarting evolution-calendar-factory solves the issue and calendars are sync again.

Version-Release number of selected component (if applicable):
evolution-data-server-3.12.11-14.el7
evolution-3.12.11-6.el7
gnome-online-accounts-3.14.4-1.el7

How reproducible:
random

Steps to Reproduce:
1. Add google account to Gnome Online Accounts
2. Run Evolution for long enough to observe the issue
Comment 1 Milan Crha 2015-06-08 15:43:56 UTC 
From the side investigation, the calendar itself (when it's working) has set:

   [Authentication]
   Host=apidata.googleusercontent.com
   Method=OAuth2

but the main .source of the GOA account has set:

   [Authentication]
   Host=
   Method=none
Comment 2 Milan Crha 2015-06-08 17:15:36 UTC 
Created attachment 1036447 [details]
debug eds patch

This should address the issue, it's a backported change currently living in the upstream sources.

I made a scratch build with it. I'd like to ask you to install it [1] and run the evolution-calendar-factory from a terminal, to see whether the password prompt condition was hit (there is a g_message() call which prints a message on the console when the condition was satisfied).

The command looks like:
   $ /usr/libexec/evolution-calendar-factory -w

You can create also a script instead of the binary to have the output logged also when the service is started by the D-Bus itself, which can be done in a similar was as in bug #1171770 comment #21, skipping step a) and doing the same only without valgrind and with 'calendar' instead of 'addressbook' in the steps.

[1] https://brewweb.devel.redhat.com/taskinfo?taskID=9322982
Comment 3 Jiri Koten 2015-06-17 09:09:21 UTC 
I got only once in a week the password prompt for the google account, but I haven't seen the message in the logs.

Also this time I didn't have to restart the backend, the calendar continues to work normally after I dismissed the prompt.

The log contains only following warnings:

(evolution-calendar-factory.orig:5474): e-cal-backend-caldav-WARNING **: Server did not response with 207, but with code 6 (SSL handshake failed)
CalDAV - failed to retrieve bunch of items
Comment 7 errata-xmlrpc 2015-11-19 07:59:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2226.html
Note You need to log in before you can comment on or make changes to this bug.