3:16 a.m.
Hi,
I've taken a peek at Google's API for tasks synchronization, which is
documented here:
https://developers.google.com/google-apps/tasks/v1/reference/ (at the
bottom of the page). The methods are used via REST which is quite easy
using libcurl if my experience in writing an REST interface for an
Amazon service is any indication.
Unless I'm missing something, this would indicate that it would be
relatively straight-forward to write a Google Tasks backend backend for
SyncEvolution, although I suspect the Google authentication procedure
might pose some problems for a non-web interface.
Has anyone taken a crack at that?
Otherwise, where do I find documentation on how to write a backend that
fits snugly into the SyncEvolution code?
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
9:53 a.m.
Hi, Ole!
I am by no means a good helper in backend writing. I'm rather a man
contesting for a "Most annoying newbie in this list" award ... and I
think I have a good chance to win :))))
But maybe my IMHO would be of a little good (for you).
On 22.09.2012 16:16:26, Ole Wolf wrote:
I've taken a peek at Google's API for tasks synchronization,
which is
[..]
Unless I'm missing something, this would indicate that it would
be
relatively straight-forward to write a Google Tasks backend for
SyncEvolution, although I suspect the Google authentication procedure
might pose some problems for a non-web interface.
Has anyone taken a crack at that?
I was looking at Evolution-data-server's Google backend and it is made
with libgdata.
libgdata is the GObject library for accessing Google APIs and it has
the ready-made OAuth implementation that could be useful for you.
Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
5:37 a.m.
On lør, 2012-09-22 at 22:53 +0600, Ildar Mulyukov wrote:
I was looking at Evolution-data-server's Google backend and it is
made
with libgdata.
libgdata is the GObject library for accessing Google APIs and it has
the ready-made OAuth implementation that could be useful for you.
Thanks. I took a closer look at libgdata, and unfortunately it seems to
use a login method that isn't supported for Google Tasks; in fact, it
seems to be using an API that was recently deprecated by Google. It
looks like I'm on my own, but my experiments thus far seem quite
promising.
If anyone is interested, the code is growing slowly on Github:
https://github.com/olewolf/gtasks2ical. "make check" of the code
currently enables me to login to Gmail, and even if this isn't quite
what I want--the Oauth2 procedure may require different pages and post
forms--at least the code indicates that it is possible to work around
Google's requirement that the user click around on web pages in a
browser.
The interface to SyncEvolution is secondary as far as I'm concerned. If
I can write a command-line utility that converts between Google Tasks
and a local iCalendar text file, it will probably be a straight-forward
task for someone else to create a SyncEvolution back-end that uses that
utility.
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
6:26 a.m.
On Thu, 2012-09-27 at 14:37 +0200, Ole Wolf wrote:
The interface to SyncEvolution is secondary as far as I'm
concerned.
If I can write a command-line utility that converts between Google
Tasks and a local iCalendar text file, it will probably be a
straight-forward task for someone else to create a SyncEvolution
back-end that uses that utility.
Such a backend has a pending feature request:
https://bugs.freedesktop.org/show_bug.cgi?id=52673
I agree that it would be fairly easy to write, but it still needs
someone to do it.
Instead of one single iCalendar file, perhaps you can write and update
individual items in a directory, where each file is a VALENDAR with a
VTODO inside? That is something that the existing file backend in
SyncEvolution can read and write. The file backend uses file
modifications to detect changes, so you would have to make sure not to
rewrite files unless they really changed.
--
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.
6:52 a.m.
On tor, 2012-09-27 at 15:26 +0200, Patrick Ohly wrote:
Instead of one single iCalendar file, perhaps you can write and
update
individual items in a directory, where each file is a VALENDAR with a
VTODO inside? That is something that the existing file backend in
SyncEvolution can read and write. The file backend uses file
modifications to detect changes, so you would have to make sure not to
rewrite files unless they really changed.
That's certainly doable. I'll probably make a single-file or multi-file
option choice available as a command-line option.
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
10:14 p.m.
On 27.09.2012 18:37:15, Ole Wolf wrote:
On lør, 2012-09-22 at 22:53 +0600, Ildar Mulyukov wrote:
> I was looking at Evolution-data-server's Google backend and it is
made
> with libgdata.
> libgdata is the GObject library for accessing Google APIs and it has
> the ready-made OAuth implementation that could be useful for you.
Thanks. I took a closer look at libgdata, and unfortunately it seems
to
use a login method that isn't supported for Google Tasks; in fact, it
seems to be using an API that was recently deprecated by Google. It
looks like I'm on my own, but my experiments thus far seem quite
promising.
"Deprecated" doesn't actually mean it doesn't work. Besides, as some
"important" apps depend on it, then one can count on it to work even
after OAuth 1 will be kicked out.
I don't intend to push you, just sharing my IMHO.
Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
12:13 a.m.
On tir, 2012-10-09 at 11:14 +0600, Ildar Mulyukov wrote:
"Deprecated" doesn't actually mean it doesn't work.
Besides, as some
"important" apps depend on it, then one can count on it to work even
after OAuth 1 will be kicked out.
True, but it's a first indication that something is going to be
intentionally broken. I prefer to keep my own code as little dependent
on maintenance as possible, and staying clear of deprecated API sections
is one way among others to avoid trouble. Besides, "deprecated"
sometimes implies little or no attention to bug fixes beyond security
issues.
I'm able to use Oauth 2 to access the tasks now, however, and the more
complicated parts of the interface to the Google Tasks is already coded
and tested, so the problem is already solved. :)
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
4:23 a.m.
one more penny from me:
I updated to Gnome 3.6 today and found that _libgdata_ and EDS use
external library now: http://liboauth.sourceforge.net/ .
But that seems to be again OAuth 1.0 . Odd.
--
Ildar
12:54 p.m.
On Sat, 2012-09-22 at 12:16 +0200, Ole Wolf wrote:
I've taken a peek at Google's API for tasks synchronization,
which is
documented here:
https://developers.google.com/google-apps/tasks/v1/reference/ (at the
bottom of the page). The methods are used via REST which is quite easy
using libcurl if my experience in writing an REST interface for an
Amazon service is any indication.
The protocol itself may be easy; I suspect the tricky part would be to
get the data handling and conversion right.
As Ildar said (Ildar, you really don't need to worry about the newbie
part :-), starting with GData might be better.
However, I am not sure whether GData supports tasks. It might not
support it (yet).
There is an open feature request about Google contacts with some hints
regarding the implementation:
https://bugs.freedesktop.org/show_bug.cgi?id=52679
As mentioned in the bug report, converting the data from Google into
vCard (or iCalendar for tasks) just to emulate existing backends (like
the one for Evolution) adds another indirection, which makes it harder
to get the data handling right. On the other hand, if GData already has
such a converter, it might be the easiest and fastest way to get
something working. It's a bit like choosing the high or the low road...
Unless I'm missing something, this would indicate that it would
be
relatively straight-forward to write a Google Tasks backend backend
for SyncEvolution, although I suspect the Google authentication
procedure might pose some problems for a non-web interface.
Has anyone taken a crack at that?
No, not beyond considering the idea and some basic research (which
probably needs to be redone anyway, because it was a year or more ago).
Otherwise, where do I find documentation on how to write a backend
that fits snugly into the SyncEvolution code?
There is an old article which gives an introduction:
http://www.estamos.de/blog/2008/08/04/syncml-client-do-it-yourself-style/
The backend API has changed since then, but the general idea is still
the same. Use the current backends as example: "file" for a simple,
TrackingSyncSource derived backend (change tracking: backend lists all
items with a unique local id and a revision string; data exchange: a
text format that can be parsed by the Synthesis engine) or
"sqlite" (more general backend, does its own change tracking and works
with the internal Synthesis representation directly).
Ignore that the title says "SyncML client" - the backends work the same
no matter for what they are used.
--
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.
11:40 p.m.
On lør, 2012-09-22 at 21:54 +0200, Patrick Ohly wrote:
There is an open feature request about Google contacts with some
hints
regarding the implementation:
https://bugs.freedesktop.org/show_bug.cgi?id=52679
I'll update the bug report with a mention of my Github code. It doesn't
currently include any SyncEvolution-aimed code, but it shows how to
access Google Tasks.
As mentioned in the bug report, converting the data from Google into
vCard (or iCalendar for tasks) just to emulate existing backends (like
the one for Evolution) adds another indirection, which makes it harder
to get the data handling right. On the other hand, if GData already has
such a converter, it might be the easiest and fastest way to get
something working.
There's also the libical library. It seems to relieve developers of the
headaches of data handling. I'll probably settle for that.
The code now reads tasks and task lists from Google Tasks and stores
them in a local format. These are by far the most difficult parts of
Google's Tasks data protocol. Updating or deleting items is much simpler
because they require much less data processing. I had some trouble with
Google's API which turned out to be buggy, but I managed to work around
it. The code currently demonstrates that Google's requirement that users
manually authorize applications to access their data can easily be
circumvented, meaning that it provides a false sense of security. All
you need to do is provide your Google username and password to an
application, and it will be able to do anything with any of your Google
data without you knowing any better.
Right now my primary concern is how to determine which Google Task
corresponds to an iCal todo entry. I hope some of you who have
experience synchronizing data can help me out here.
Google Tasks have unique IDs, but they're read-only. So if the Google
Task is created first, then the Google Task ID could be used as a UID.
However, if the iCal todo is created first, then its UID cannot be
copied to the Google Task ID. Similarly, a Google Task includes a
self-link which uniquely identifies the task (basically because its UID
is repeated in the self-link; hopefully this data redundancy doesn't
reflect the design of Google's Tasks database), but it's read-only, too.
This leaves only "due date," "title," and "notes" as
candidates for
identifying the tasks, and even they are rather prone to change.
Is it generally acceptable to create, say, an "x-google-task-uid:" with
the Google Task ID in the VTODO section and use that to synchronize
with?
Similarly, since Google Tasks include a handful of fields that don't
correspond to any iCalendar keys, should they be named with some
"x-google-task-<property>"?
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
12:50 a.m.
On Tue, 2012-10-02 at 08:40 +0200, Ole Wolf wrote:
On lør, 2012-09-22 at 21:54 +0200, Patrick Ohly wrote:
I had some trouble with Google's API which turned out to be buggy, but
I managed to work around it.
Can you provide details? I'm currently at CalConnect, sitting a few
chairs away from Google developers who work on the GData API. I can try
to get them to look at these bugs.
The code currently demonstrates that Google's requirement that
users
manually authorize applications to access their data can easily be
circumvented, meaning that it provides a false sense of security. All
you need to do is provide your Google username and password to an
application, and it will be able to do anything with any of your
Google data without you knowing any better.
Your probably mean the two-factor login? Can you point me to the code
which circumvents that requirement and/or provide a high-level
description how that is done?
I have a hunch that you use the main username/password to create per-app
passwords. I don't think two-factor login is meant to protect against
that. As soon as someone has the main username/password, obviously the
door is wide open.
What per-app passwords provide is limitation of damage that occurs when
those passwords are leaked. Instead of having access to everything, the
attacker only has access to a subset of the Google services.
Incidentally, enabling two-factor login leads to a hard to debug user
error: I had done that a while back, then tried to log into Google
CardDAV with my main username/password, which failed with a 401
credential error. There was no hint that I had to create per-app
credentials as part of the HTTP error message, which made it hard to
make the connection to two-factor login as the root cause.
A single-sign-on system with Google support would have helped a lot
here.
Right now my primary concern is how to determine which Google Task
corresponds to an iCal todo entry. I hope some of you who have
experience synchronizing data can help me out here.
Google Tasks have unique IDs, but they're read-only. So if the Google
Task is created first, then the Google Task ID could be used as a UID.
However, if the iCal todo is created first, then its UID cannot be
copied to the Google Task ID. Similarly, a Google Task includes a
self-link which uniquely identifies the task (basically because its
UID is repeated in the self-link; hopefully this data redundancy
doesn't reflect the design of Google's Tasks database), but it's
read-only, too. This leaves only "due date," "title," and
"notes" as
candidates for identifying the tasks, and even they are rather prone
to change.
Is it generally acceptable to create, say, an "x-google-task-uid:"
with the Google Task ID in the VTODO section and use that to
synchronize with?
Similarly, since Google Tasks include a handful of fields that don't
correspond to any iCalendar keys, should they be named with some
"x-google-task-<property>"?
Both would be possible and desirable.
--
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.
3:09 a.m.
On tir, 2012-10-02 at 09:50 +0200, Patrick Ohly wrote:
> I had some trouble with Google's API which turned out to be
buggy, but
> I managed to work around it.
Can you provide details? I'm currently at CalConnect, sitting a few
chairs away from Google developers who work on the GData API. I can try
to get them to look at these bugs.
Sure. I had originally wanted to register the application as a device
(not because it is really a device, but because it would simplify
certain automatic web page decoding). When a device attempts to use the
tasks scope, the REST interface reports that the scope is invalid. This
is apparently due to a missing "whitelist" at Google. Connecting as an
application works, though, so I had to revert to this method.
> The code currently demonstrates that Google's requirement
that users
> manually authorize applications to access their data can easily be
> circumvented, meaning that it provides a false sense of security. All
> you need to do is provide your Google username and password to an
> application, and it will be able to do anything with any of your
> Google data without you knowing any better.
Your probably mean the two-factor login? Can you point me to the code
which circumvents that requirement and/or provide a high-level
description how that is done?
It's relatively easy: first, the application opens a login page and
identifies the login form. Then it fills the Email and Passwd entries
with the user's Google username (user(a)gmail.com) and password and
submits the form. The session now includes the Google login. Next, the
application requests the page where the user authorizes it to access his
or her data, then decodes the approval form and submits it. The
functions that handle all this are called "login_to_gmail" and
"authorize_application" and are both found in the file google-oauth2.c.
I have a hunch that you use the main username/password to create
per-app
passwords. I don't think two-factor login is meant to protect against
that. As soon as someone has the main username/password, obviously the
door is wide open.
Indeed. I had no idea there even was a per-app password. I wonder how
many users are aware of that.
Both would be possible and desirable.
Thanks. I'll probably look into the syntax of some widely used "X-blank"
properties and see if I can use those. For example, if some of the
Google Tasks-specific fields are also provided by Outlook, then it would
probably make sense to just use Outlook's X-prop key and formatting.
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
12:59 a.m.
On 2.10.2012 9:40, Ole Wolf wrote:
The code currently demonstrates that Google's requirement that
users
manually authorize applications to access their data can easily be
circumvented, meaning that it provides a false sense of security. All
you need to do is provide your Google username and password to an
application, and it will be able to do anything with any of your Google
data without you knowing any better.
Users should never enter their Google credentials to any application
asking for those. Only in either browser authorization page or in a
trusted SSO user agent. The needed methods are clearly outlined in OAuth
1/2 RFCs. Of course nothing will protect users if they willingly give
the credentials to untrusted party.
Otherwise it becomes notable security risk because the same account
credentials are used to authorize credit card payments in context of
Play store, AdWords, etc.
1:20 a.m.
On Tue, 2012-10-02 at 10:59 +0300, Jussi Laako wrote:
On 2.10.2012 9:40, Ole Wolf wrote:
> The code currently demonstrates that Google's requirement that users
> manually authorize applications to access their data can easily be
> circumvented, meaning that it provides a false sense of security. All
> you need to do is provide your Google username and password to an
> application, and it will be able to do anything with any of your Google
> data without you knowing any better.
Users should never enter their Google credentials to any application
asking for those. Only in either browser authorization page or in a
trusted SSO user agent.
The problem is that on most Linux systems, neither browser nor such a
SSO agent are currently necessarily safer or more trustworthy than the
app itself. But I agree that reducing the amount of code which gets
access to the main credentials is a step in the right direction.
A benefit for users on unsecured systems is that the central code can be
taught to set up two-factor credentials for an app, to detect when
Google wants an acknowledgment via the web browser from the user, etc.
Replicating that in all apps which need to log into Google is just a
duplication of effort.
--
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.
5:25 a.m.
On 2.10.2012 11:20, Patrick Ohly wrote:
The problem is that on most Linux systems, neither browser nor such
a
SSO agent are currently necessarily safer or more trustworthy than the
app itself.
Generally browsers are fairly well tested and users have to trust those
for many of the online commerce things anyway. In any case, asking user
credentials from application clearly attempts to violate two-factor
authentication scheme.
SSO will, AFAIK, ship in Ubuntu 12.10, but I haven't got time to check
how they configured it. You can run the daemon under different user id
than the user's. And with SMACK-enabled kernel you get full two-level
local access control (you can define which process in which context can
ask for what, per each stored item). It would be fairly trivial to make
it support SELinux too, just matter of writing a simple extension class.
At rudimentary level (lacking SMACK/SELinux) you could specify ACL per
binary path defining what kind of requests are allowed.
1:56 a.m.
Jussi Laako <jussi.laako@...> writes:
On 2.10.2012 11:20, Patrick Ohly wrote:
> The problem is that on most Linux systems, neither browser nor such a
> SSO agent are currently necessarily safer or more trustworthy than the
> app itself.
Generally browsers are fairly well tested and users have to trust those
for many of the online commerce things anyway. In any case, asking user
credentials from application clearly attempts to violate two-factor
authentication scheme.
SSO will, AFAIK, ship in Ubuntu 12.10, but I haven't got time to check
how they configured it. You can run the daemon under different user id
than the user's. And with SMACK-enabled kernel you get full two-level
local access control (you can define which process in which context can
ask for what, per each stored item). It would be fairly trivial to make
it support SELinux too, just matter of writing a simple extension class.
At rudimentary level (lacking SMACK/SELinux) you could specify ACL per
binary path defining what kind of requests are allowed.
I have no clue about programming such things but I am also very interested to
sync google tasks (and also google "notes" --> word documents in google
drive)
via syncevolution 1.3 to my Nokia N9.
Maybe one hint/source of information for you is the code of software "gSyncit
v3.x" by David Levinson/Fieldston Software. gSyncit syncs (my) Outlook task to
google tasks and Outlook notes as google drive word documents (also Outlook
contacts, Outlook calendar).
I would really appriciate a solution to sync tasks (and contacts) through
syncevolution and also would support efforts by a donation.
kind regards
Benjamin
3548
days inactive
3566
days old
syncevolution@synevolution.org
15 comments
5 participants
participants (5)
-
Benjamin -
Ildar Mulyukov -
Jussi Laako -
Ole Wolf -
Patrick Ohly