On Thu, 2013-07-11 at 17:07 +0200, Patrick Ohly wrote: > - Walk through specific flow for Google CalDAV and CardDAV, including > the configure options needed to provide the keys and what the SSO > backend would get from SyncEvolution.
Let's consider a naive attempt to use Google CalDAV: $ SYNCEVOLUTION_DEBUG=1 syncevolution --print-items --daemon=no backend=caldav loglevel=4 syncurl=https://apidata.googleusercontent.com/caldav/v2 The commands fail with "403 Forbidden" and a rather unspecific application/vnd.google.gdata.error+xml error which points towards the need to register the app (see google-caldav.log, attached). >From that the client may conclude that it is dealing with a Google service. But that could be misleading. For example, what if some other service uses the same error format? The <extendedHelp>https://code.google.com/apis/console</extendedHelp> is a bit more Google specific, but looking at the content of a help text just doesn't feel right. IMHO this boils down to the need to determine the authorization method beforehand. According to https://developers.google.com/accounts/docs/OAuth2InstalledApp https://developers.google.com/google-apps/calendar/auth the following pieces of information are needed for OAuth2: end point: https://accounts.google.com/o/oauth2/auth scope: https://www.googleapis.com/auth/calendar client_id: xxxx redirect_uri: as registered for that client_id Is the end point something that must be passed to (g)SSO or is it something that it already knows? What "redirect_uri" should be used when registering SyncEvolution? The information above could be provided to SyncEvolution at runtime in a /usr/share/syncevolution/authentication/google-calendar.ini file. The content of that file is determined by the packager. In addition, files could also be searched for in ~/.local/share/syncevolution/authentication or /etc/syncevolution/authentication. That way, a user and/or system admin could personalize or add services without having to recompile SyncEvolution. To use OAuth2, the user would need to use: username = gSSO+google-calendar:[email protected] password = Note the extra "+google-calendar": that tells SyncEvolution to use the "google-calendar" authentication method. How much it needs to know about the method is open for debate - it could be treated as key/value store whose pairs SyncEvolution simply passes through to the SSO backend without caring about the content, or it could simply pass the string itself to the backend and let the backend resolve it. The password was empty above. It could also be set by the user, with the expectation that the SSO backend then uses that instead of triggering any prompts. When used during "--configure", it could be used like this: syncevolution --configure \ username=gSSO:[email protected] \ password=foobar No peer config needs to be specified on the command line in this case (a deviation from the current command line syntax!), instead the "foobar" password and "[email protected]" string will be handed over to the SSO backend with the expectation that it'll store the password as securely as it can for use later on. At runtime, when given "username = gSSO+<service>:[email protected]", SyncEvolution will ask the backend for the kind of authorization that it needs to use. Possible options, depending on the actual <service> value and the .ini file it references: - traditional username/password, with both provided to SyncEvolution by the backend - OAuth2 access token For service=google-calendar, then answer would always be OAuth2. For service=credentials, it is username/password. Again it is open for debate whether there really needs to be a credentials.ini file for that, or whether just the string alone could have that special meaning. When using an access token, SyncEvolution must be aware that it will have to ask for another token when it gets authentication errors. Or how else would it detect that the token expired? Does this all sound reasonable so far? Can someone explain how that'll map to APIs and functionality in gSSO and UOA? -- 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.
[DEBUG 00:00:00] using libneon neon 0.29.6: Library build, IPv6, libxml 2.7.8, zlib 1.2.6, GNU TLS 2.12.18. with SSL, ZLIB, IPV6, TS_SSL, I18N [DEBUG 00:00:00] : timout 300s, retry 5s => resending allowed HTTP session to https://apidata.googleusercontent.com:443 begins. [DEBUG 00:00:00] client cert is missing [DEBUG 00:00:00] testing /caldav/v2/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /caldav/v2/ [DEBUG 00:00:00] starting PROPFIND, credentials unverified, no deadline ah_create, for WWW-Authenticate Running pre_send hooks Sending request headers: PROPFIND /caldav/v2/ HTTP/1.1 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Host: apidata.googleusercontent.com Depth: 0 Content-Length: 84 Content-Type: application/xml Sending request-line and headers: Doing DNS lookup on apidata.googleusercontent.com... req: Connecting to 173.194.33.44:443 Sending request body: Body block (84 bytes): [<?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><allprop/></propfind> ] Request sent; retry is 0. [status-line] < HTTP/1.1 403 Forbidden [hdr] Content-Type: application/vnd.google.gdata.error+xml; charset=UTF-8 Header Name: [content-type], Value: [application/vnd.google.gdata.error+xml; charset=UTF-8] [hdr] Date: Fri, 12 Jul 2013 11:53:51 GMT Header Name: [date], Value: [Fri, 12 Jul 2013 11:53:51 GMT] [hdr] Expires: Fri, 12 Jul 2013 11:53:51 GMT Header Name: [expires], Value: [Fri, 12 Jul 2013 11:53:51 GMT] [hdr] Cache-Control: private, max-age=0 Header Name: [cache-control], Value: [private, max-age=0] [hdr] X-Content-Type-Options: nosniff Header Name: [x-content-type-options], Value: [nosniff] [hdr] X-Frame-Options: SAMEORIGIN Header Name: [x-frame-options], Value: [SAMEORIGIN] [hdr] X-XSS-Protection: 1; mode=block Header Name: [x-xss-protection], Value: [1; mode=block] [hdr] Server: GSE Header Name: [server], Value: [GSE] [hdr] Transfer-Encoding: chunked Header Name: [transfer-encoding], Value: [chunked] [hdr] End of headers. Running post_headers hooks [chunk] < 170 Got chunk size: 368 Reading 368 bytes of response body. Got 368 bytes. Read block (368 bytes): [<?xml version="1.0" encoding="UTF-8"?> <errors xmlns="http://schemas.google.com/g/2005";> <error> <domain>usageLimits</domain> <code>dailyLimitExceededUnreg</code> <internalReason>Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.</internalReason> <extendedHelp>https://code.google.com/apis/console</extendedHelp> </error> </errors> ] [chunk] < 0 Got chunk size: 0 [hdr] End of headers. Running post_send hooks ah_post_send (#0), code is 403 (want 401), WWW-Authenticate is (none) Request ends, status 403 class 4xx, error line: 403 Forbidden [DEBUG 00:00:01] PROPFIND: Neon error code 1: 403 Forbidden, must not retry Running destroy hooks. Request ends. [DEBUG 00:00:01] : exception thrown at /home/pohly/syncevolution/syncevolution/src/backends/webdav/NeonCXX.cpp:723 [DEBUG 00:00:01] : error code from SyncEvolution access denied (remote, status 403): PROPFIND: Neon error code 1: 403 Forbidden [DEBUG 00:00:01] read relevant properties of /caldav/v2/ [DEBUG 00:00:01] starting PROPFIND, credentials unverified, deadline in 298.9s ah_create, for WWW-Authenticate Running pre_send hooks Sending request headers: PROPFIND /caldav/v2/ HTTP/1.1 Connection: TE TE: trailers Host: apidata.googleusercontent.com Depth: 0 Content-Length: 925 Content-Type: application/xml Sending request-line and headers: Sending request body: Body block (925 bytes): [<?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><prop> <alternate-URI-set xmlns="DAV:"/> <principal-URL xmlns="DAV:"/> <current-user-principal xmlns="DAV:"/> <group-member-set xmlns="DAV:"/> <group-membership xmlns="DAV:"/> <displayname xmlns="DAV:"/> <resourcetype xmlns="DAV:"/> <calendar-home-set xmlns="urn:ietf:params:xml:ns:caldav"/> <calendar-description xmlns="urn:ietf:params:xml:ns:caldav"/> <calendar-timezone xmlns="urn:ietf:params:xml:ns:caldav"/> <supported-calendar-component-set xmlns="urn:ietf:params:xml:ns:caldav"/> <supported-calendar-data xmlns="urn:ietf:params:xml:ns:caldav"/> <max-resource-size xmlns="urn:ietf:params:xml:ns:caldav"/> <min-date-time xmlns="urn:ietf:params:xml:ns:caldav"/> <max-date-time xmlns="urn:ietf:params:xml:ns:caldav"/> <max-instances xmlns="urn:ietf:params:xml:ns:caldav"/> <max-attendees-per-instance xmlns="urn:ietf:params:xml:ns:caldav"/> </prop></propfind> ] Request sent; retry is 1. [status-line] < HTTP/1.1 403 Forbidden [hdr] Content-Type: application/vnd.google.gdata.error+xml; charset=UTF-8 Header Name: [content-type], Value: [application/vnd.google.gdata.error+xml; charset=UTF-8] [hdr] Date: Fri, 12 Jul 2013 11:53:51 GMT Header Name: [date], Value: [Fri, 12 Jul 2013 11:53:51 GMT] [hdr] Expires: Fri, 12 Jul 2013 11:53:51 GMT Header Name: [expires], Value: [Fri, 12 Jul 2013 11:53:51 GMT] [hdr] Cache-Control: private, max-age=0 Header Name: [cache-control], Value: [private, max-age=0] [hdr] X-Content-Type-Options: nosniff Header Name: [x-content-type-options], Value: [nosniff] [hdr] X-Frame-Options: SAMEORIGIN Header Name: [x-frame-options], Value: [SAMEORIGIN] [hdr] X-XSS-Protection: 1; mode=block Header Name: [x-xss-protection], Value: [1; mode=block] [hdr] Server: GSE Header Name: [server], Value: [GSE] [hdr] Transfer-Encoding: chunked Header Name: [transfer-encoding], Value: [chunked] [hdr] End of headers. Running post_headers hooks [chunk] < 170 Got chunk size: 368 Reading 368 bytes of response body. Got 368 bytes. Read block (368 bytes): [<?xml version="1.0" encoding="UTF-8"?> <errors xmlns="http://schemas.google.com/g/2005";> <error> <domain>usageLimits</domain> <code>dailyLimitExceededUnreg</code> <internalReason>Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.</internalReason> <extendedHelp>https://code.google.com/apis/console</extendedHelp> </error> </errors> ] [chunk] < 0 Got chunk size: 0 [hdr] End of headers. Running post_send hooks ah_post_send (#0), code is 403 (want 401), WWW-Authenticate is (none) Request ends, status 403 class 4xx, error line: 403 Forbidden [DEBUG 00:00:01] PROPFIND: Neon error code 1: 403 Forbidden, must not retry Running destroy hooks. Request ends. [DEBUG 00:00:01] TransportStatusException: PROPFIND: Neon error code 1: 403 Forbidden [DEBUG 00:00:01] exception thrown at /home/pohly/syncevolution/syncevolution/src/backends/webdav/NeonCXX.cpp:723 [ERROR 00:00:01] error code from SyncEvolution access denied (remote, status 403): PROPFIND: Neon error code 1: 403 Forbidden [ERROR 00:00:01] : reading items sess: Destroying session.
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
