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.