[SyncEvolution] getting started with gSSO (was: Re: SyncEvolution + SSO + credentials)
by Patrick Ohly
Hello!
Without my knowledge, the mailing list configuration was changes such
that mails from unsubscribed senders were automatically discarded. That
was unintentional. I've changed it back so that I get a chance to
approve individual posts and senders again - no need to subscribe to the
list.
After this service announcement, back to the topic - see below...
On Fri, 2013-07-19 at 14:48 +0300, Alexander Kanavin wrote:
> On 07/15/2013 10:44 AM, Valluri, Amarnath wrote:
>
> > I am working on gtk based UI for gSSO, It is about to ready, testing is going on.
> > I guess by this weekend, i can push the functional UI.
>
> We're still testing the UI, it almost works :) Also real-world testing
> uncovered some other bugs in gSSO that were invisible with
> self-contained testing.
>
> I'm taking a one-week vacation next week, but Amarnath will continue the
> work, and he can also help you to set up gSSO and play with the example
> (work in progress is here, and the complete example should be only a
> little longer:
> http://code.google.com/p/accounts-sso/source/browse/examples/google-oauth...
> ).
As a first step, I compiled accounts-sso.libgsignon-glib,
accounts-sso.gsignond and accounts-sso.gsignond-plugin-oa from
https://code.google.com/p/accounts-sso/source/checkout
I had to patch gsignond slightly to fix autotools build issues with
out-of-tree compilation. Compilation of accounts-sso.gsignond-plugin-oa
also required one tweak. Patches attached.
I'm now at the stage where files are installed. What's next?
Running gsignond-oauth2-example with (or without) gsignond running
promply segfaults (missing error handling somewhere?):
Program received signal SIGSEGV, Segmentation fault.
0x00000000008de8d0 in ?? ()
(gdb) where
#0 0x00000000008de8d0 in ?? ()
#1 0x00007ffff6874669 in g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=0x8de8d0,
hash_table=0x8de410) at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/ghash.c:401
#2 g_hash_table_lookup (hash_table=hash_table@entry=0x8de410, key=key@entry=0x8de8d0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/ghash.c:1074
#3 0x00007ffff779bb47 in gsignond_dictionary_get (dict=dict@entry=0x8de410, key=key@entry=0x8de8d0 "megaclient")
at /home/pohly/src/accounts-sso/accounts-sso.gsignond/src/common/gsignond-dictionary.c:151
#4 0x00007ffff7bd88f6 in _process_oauth2_request (self=self@entry=0x611000,
session_data=session_data@entry=0x893400, tokens=tokens@entry=0x8de410)
at /home/pohly/src/accounts-sso/accounts-sso.gsignond-plugin-oa/src/gsignond-oauth-plugin-oauth2.c:554
#5 0x00007ffff7bd758e in gsignond_oauth_plugin_request_initial (plugin=0x611000, session_data=0x893400,
token_cache=0x8de410, mechanism=0x401870 "oauth2")
at /home/pohly/src/accounts-sso/accounts-sso.gsignond-plugin-oa/src/gsignond-oauth-plugin.c:426
#6 0x00000000004013aa in main ()
at /home/pohly/src/accounts-sso/accounts-sso.gsignond-plugin-oa/examples/gsignond-oauth2-example.c:153
--
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.
7 years, 8 months
Re: [SyncEvolution] one-way-sync not respected
by Patrick Ohly
On Mon, 2013-07-22 at 07:06 -0300, Juan Antonio Zuloaga Mellino wrote:
> I realize I didn't explain myself properly:
>
> Google requires authentication for accessing the caldav api.
>
> On public calendars, any authentication credentials are accepted for
> reading public calendars.
>
> Trying to write on remote without ownership produces the 403 error.
> Reading doesn't produce it. I don't know if that's expected.
>
> Why does syncevolution try to access writing functions, if one-way
> sync was selected?
The log helped. Something is going wrong with change detection: the
remote side is requesting an "Add" of an item which already exists
locally.
The local side then eventually comes to the conclusion that the remote
side has too many items and tries to delete some. It shouldn't do that
and the remote side rejects that without ever trying to write to
Google.
In other words, sync is one-way as intended, it just doesn't quite work
as intended. I'll try to reproduce here.
--
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.
7 years, 8 months
Re: [SyncEvolution] one-way-sync not respected
by Juan Antonio Zuloaga Mellino
*A correction, syncevolution was called with:
syncevolution --sync one-way-from-remote feriados
2013/7/22 Juan Antonio Zuloaga Mellino <skirhir(a)gmail.com>:
> I realize I didn't explain myself properly:
>
> Google requires authentication for accessing the caldav api.
>
> On public calendars, any authentication credentials are accepted for
> reading public calendars.
>
> Trying to write on remote without ownership of the calendar produces
> the 403 error.
>
> Why does syncevolution try to access writing functions, if one-way
> sync was selected?
>
> Log attached.
>
> syncevolution was called with
>
> $>syncevolution --sync local-cache-incremental feriados
>
>
> 2013/7/22 Patrick Ohly <patrick.ohly(a)intel.com>:
>> On Mon, 2013-07-22 at 00:15 -0300, Juan Antonio Zuloaga Mellino wrote:
>>> Found this when I tried to sync google public calendars with
>>> syncevolution (as an ics subscription replacement).
>>>
>>> It seems that google still requires authentication even for accessing
>>> public calendars. ie:
>>> https://www.google.com/calendar/dav/vi6voh10oa187gg9nvs8pkqt7s@group.cale...
>>>
>>> Even with one-way-from-remote it exits with 403 (Auth required). The
>>> synchronization is successful.
>>>
>>> If required, I could attach the log.
>>
>> I'm not exactly sure what the problem is. If Google requires
>> authentication, then there is little that SyncEvolution can do about
>> that, can't it?
>>
>> Or is the problem that reading the data fails, and then it skips over
>> that error and doesn't report a sync failure? In that case a log would
>> indeed be useful.
>>
>> --
>> 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.
>>
>>
7 years, 9 months
Re: [SyncEvolution] sync timeouts for syncevo-http-server + nokia e51 phone
by Christof Schulze
Hello,
> was not replying to the list intentional or may I copy the list again?
No that was not intentional. Sorry about that.
> I tried getting a trace using 1.3.99.4 however the thread did not
> crash when having a Timetout of one minute set.
I guess this is off the table for now as I also tried commenting out
the RetryDuration - still no crash with the newest version. Maybe it
was a bug in 1.3.99.3 that was already fixed?
> > [DEBUG] syncevo-http: processing incoming message of type
> > application/vnd.syncml+wbxml and length 411, binary data
> > [ERROR] sync: /org/syncevolution/Session/5101776841374092036: error code
> > from SyncEvolution data merged (remote, status 207): updateAllSubItems
> > REPORT 'multiget new/updated items': Neon error code 1: Could not parse
> > response: XML parse error at line 52675: PCDATA invalid Char value 1
> > In the log I can see:
> > [2013-07-17 22:43:23.951] stderr: XML: Parsing 8000 bytes.
> What is before that? There should be some output from Neon starting with
> a REPORT as HTTP operation and a request body like this:
> "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n"
> "<C:calendar-query xmlns:D=\"DAV:\"\n"
> "xmlns:C=\"urn:ietf:params:xml:ns:caldav\">\n"
> "<D:prop>\n"
> "<D:getetag/>\n"
> "</D:prop>\n"
> // filter expected by Yahoo! Calendar
> "<C:filter>\n"
> "<C:comp-filter name=\"VCALENDAR\">\n"
> "<C:comp-filter name=\"VEVENT\">\n"
> "</C:comp-filter>\n"
> "</C:comp-filter>\n"
> "</C:filter>\n"
> "</C:calendar-query>\n";
> The response to that should also be logged. It is then getting
> parsed as XML, which fails.
I did try this in the log directory:
for i in *.xml
do
xmllint $i >/dev/null
echo $?
done
That reported success for every xml file that is in the directory.
Now I looked into the logfile again and I also found these:
[2013-07-17 22:41:45.372] Warning: More than 3 consecutive Alert 222 - looks
like endless loop, check if we need to work around client implementation
issues
[2013-07-17 22:41:45.372] Alert: command finished execution -> deleting
actually I feel this log is rather interesting. If you like, I can place
it online.
I looked a little further into the logfile and found this:
[2013-07-17 22:43:23.905] stderr: Header Name: [transfer-encoding], Value:
[chunked]
[2013-07-17 22:43:23.905] stderr: [hdr] Content-Type: application/xml;
charset=utf-8
[2013-07-17 22:43:23.905] stderr: Header Name: [content-type], Value:
[application/xml; charset=utf-8]
[2013-07-17 22:43:23.906] stderr: [hdr]
[2013-07-17 22:43:23.906] stderr: End of headers.
[2013-07-17 22:43:23.906] stderr: Running post_headers hooks
[2013-07-17 22:43:23.906] stderr: [chunk] < 2a7581
[2013-07-17 22:43:23.906] stderr: Got chunk size: 2782593
[2013-07-17 22:43:23.906] stderr: Reading 8000 bytes of response body.
[2013-07-17 22:43:23.912] stderr: Got 8000 bytes.
[2013-07-17 22:43:23.914] stderr: Read block (8000 bytes):
[<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"
xmlns:cal="urn:ietf:params:xml:ns:caldav"
xmlns:cs="http://calendarserver.org/ns/"><d:response><d:href>/owncloud/apps/calendar/caldav.php/calendars/christof/defaultcalendar/01102012130248332750-0.ics</d:href><d:propstat><d:prop><cal:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.45//EN
BEGIN:VEVENT
STATUS:CONFIRMED
LAST-MODIFIED:20121001T130248Z
DTSTAMP:20121001T130248Z
UID:01102012130248332750-0
SEQUENCE:0
CLASS:PUBLIC
PRIORITY:0
SUMMARY:DR\\, AAA AAAAA
DTSTART:20121001T120000Z
DTEND:20121001T170000Z
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT10M
ACTION:DISPLAY
DESCRIPTION:z:systemSystemSoundsalarm.wav
END:VALARM
END:VEVENT
END:VCALENDAR
SNIP
I did cut out quite a bit until the end of this chunk.
</cal:calendar-
data><d:getetag>"64585e1c80459c9ccc4163a5190b2f16"</d:getetag></d:prop><d:status>HTTP/1.1
200
OK</d:status></d:propstat></d:response><d:response><d:href>/owncloud/apps/calendar/caldav.php/calendars/christof/defaultcalendar/01112012134617286750-0.ics</d:href><d:propstat><d:prop><cal:calendar-
data>BEGIN:VCALENDAR
VER]
[2013-07-17 22:43:23.920] stderr: XML: Parsing 8000 bytes.
[2013-07-17 22:43:23.920] stderr: XML: start-element (0, {DAV:, multistatus})
=> 1
[2013-07-17 22:43:23.921] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.921] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.921] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.921] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.921] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.921] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.922] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.922] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.922] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.922] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.923] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.923] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.923] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.923] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.923] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.923] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.924] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.924] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.924] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.924] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.924] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.924] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.925] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.925] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.925] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.925] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.925] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.926] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.926] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.926] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.926] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.926] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.926] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.927] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.927] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.927] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.927] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.927] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.927] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.928] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.928] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.928] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.928] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.929] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.929] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.929] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.929] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.929] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.930] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.930] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.930] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.930] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.931] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.931] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.931] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.931] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.931] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.931] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.932] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.932] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.932] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.932] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.932] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.932] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.932] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.933] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.933] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.933] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.933] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.933] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.933] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.934] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.934] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.934] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.934] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.934] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.934] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.935] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.935] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.935] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.935] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.935] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.935] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.936] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.936] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.936] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.936] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.936] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.936] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.937] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.937] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.937] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.937] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.937] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.937] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.938] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.938] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.938] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.938] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.938] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.938] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.939] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.939] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.939] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.939] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.939] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.939] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.940] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.941] stderr: XML: end-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data})
[2013-07-17 22:43:23.941] stderr: XML: start-element (1, {DAV:, getetag}) => 1
[2013-07-17 22:43:23.941] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.941] stderr: XML: end-element (1, {DAV:, getetag})
[2013-07-17 22:43:23.941] stderr: XML: end-element (1, {DAV:, prop})
[2013-07-17 22:43:23.941] stderr: XML: start-element (1, {DAV:, status}) => 1
[2013-07-17 22:43:23.942] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.942] stderr: XML: end-element (1, {DAV:, status})
[2013-07-17 22:43:23.942] stderr: XML: end-element (1, {DAV:, propstat})
[2013-07-17 22:43:23.942] stderr: XML: end-element (1, {DAV:, response})
[2013-07-17 22:43:23.942] stderr: XML: start-element (1, {DAV:, response}) =>
1
[2013-07-17 22:43:23.942] stderr: XML: start-element (1, {DAV:, href}) => 1
[2013-07-17 22:43:23.943] stderr: XML: char-data (1) returns 0
[2013-07-17 22:43:23.943] stderr: XML: end-element (1, {DAV:, href})
[2013-07-17 22:43:23.943] stderr: XML: start-element (1, {DAV:, propstat}) =>
1
[2013-07-17 22:43:23.943] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.943] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.943] stderr: XML: xmlParseChunk returned 0
[2013-07-17 22:43:23.944] stderr: Reading 8000 bytes of response body.
[2013-07-17 22:43:23.944] stderr: Got 8000 bytes.
[2013-07-17 22:43:23.945] stderr: Read block (8000 bytes):
......
t-element (1, {DAV:, propstat}) => 1
[2013-07-17 22:43:23.943] stderr: XML: start-element (1, {DAV:, prop}) => 1
[2013-07-17 22:43:23.943] stderr: XML: start-element (1,
{urn:ietf:params:xml:ns:caldav, calendar-data}) => 1
[2013-07-17 22:43:23.943] stderr: XML: xmlParseChunk returned 0
[2013-07-17 22:43:23.944] stderr: Reading 8000 bytes of response body.
[2013-07-17 22:43:23.944] stderr: Got 8000 bytes.
[2013-07-17 22:43:23.945] stderr: Read block (8000 bytes):
[SION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.45//EN
BEGIN:VEVENT
LAST-MODIFIED:20121105T110647Z
DTSTAMP:20121105T110647Z
UID:01112012134617286750-0
SEQUENCE:0
CLASS:PUBLIC
PRIORITY:0
SUMMARY:Abschiedsfeier
apparently the chunking cuts off events at fixed byte offsets - in this
case between VER an SION so I would doubt that each chunkg is ever a
valid xml on large syncs where multiple chunks are needed.
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
7 years, 9 months
[SyncEvolution] sync timeouts for syncevo-http-server + nokia e51 phone
by Christof Schulze
Hi,
Since syncevo-http-server is now running I was going to synchronize my
calender (4200 entries) with owncloud that already contained most of the
data.
I started with a one-way-sync from phone to syncevo-http-server.
This caused syncevolution to remove all data from owncloud, which is
perfectly fine. However doing so takes about one second for each entry
causing the phone to report a timeout after a while.
What is your take on that? Shouldn't syncevo-http-server try to keep the
session to the phone open? Maybe a better approach would be to clean all
files at once on the webdav server to circumvent the timeout in the
first place?
Regards
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
7 years, 9 months
Re: [SyncEvolution] SyncEvolution + SSO + credentials
by Patrick Ohly
On Mon, 2013-07-15 at 07:46 +0000, Kanavin, Alexander wrote:
> Accounts enumeration and configuration retrieval is done by libaccounts,
> but the authentication part is done by libsignon or libgsignon. I think
> you're confusing the two here.
>
> This is actually a good overview:
> http://developer.ubuntu.com/resources/technologies/online-accounts/
> http://developer.ubuntu.com/resources/technologies/online-accounts/for-ap...
>
> Also (this is for Patrick) the libaccounts part is optional and you don't
> have to use it. You can store the configuration any way you want, but then
> you will lose the integration with platforms' account management.
I've already seen that and noticed that libsignon gets a copy of the
values from an account, not a reference to the account itself.
Is libsignon also used in gSSO? So far, only libaccounts-glib was
mentioned.
--
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.
7 years, 9 months
Re: [SyncEvolution] SyncEvolution + SSO + credentials
by Patrick Ohly
On Mon, 2013-07-15 at 09:23 +0300, Alberto Mardegan wrote:
> Hi all!
>
> I'm replying inline:
>
> > > -----Original Message-----
> > > From: Patrick Ohly [mailto:patrick.ohly@intel.com
> > <mailto:patrick.ohly@intel.com>]
> > > Sent: Friday, July 12, 2013 3:54 PM
> > > To: SyncEvolution
> > > Cc: ken(a)vandine.org <mailto:ken@vandine.org>; Laako, Jussi;
> > Kanavin, Alexander
> > > Subject: Re: SyncEvolution + SSO + credentials
> > >
> > > 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?
>
> All this information (end point, scope, client id, redirect uri) can be
> known by libaccounts-glib itself, if stored in a .service file in
> /usr/share/accounts/services/ (if you use a recent Ubuntu distribution,
> you can already see what's in there).
If I were to try that in a chroot, which packages do I need to install?
> And they can be overriden by the
> application, if it wants to.
> You can read more about that here:
> http://developer.ubuntu.com/resources/technologies/online-accounts/for-se...
"creating a binary plugin which the Online Accounts configuration applet
will load" - while that may be useful for best integration into Ubuntu
(or Ubuntu Phone), this is not something that I want to depend on in
core SyncEvolution. I would accept patch contributions for an optional
component, if someone wants to write and maintain such a plugin as part
of SyncEvolution.
The key part would be to figure out whether the user wants to sync a
certain calendar or address book, then create the corresponding local
EDS database, SyncEvolution config and trigger syncing.
I think SyncEvolution should not do that automatically. Otherwise
enabling, say, the Google account in UOA for Evolution and installing
SyncEvolution for syncing with a phone would suddenly end up mirroring
Google data.
> > > 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:john.doe@gmail.com
> > <mailto:gSSO%2Bgoogle-calendar%3Ajohn.doe@gmail.com>
> > > 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 libaccounts backend doesn't need any of that information:
> libaccounts will know how to enumerate the accounts which are
> interesting for SyncEvolution, and will be able to authenticate against
> them. It will return the credentials information (OAuth token,
> username/password pair) plus the information of what this information is
> (whether it's a token or username/password). It can also return other
> information about the service (such as the server URL and port, and
> additional parameters).
>
> What I wonder about here is: can't we just reuse the libaccounts (or
> GOA) backends we have for Evolution? After all, to me it looks like they
> would perform exactly the same task.
Probably yes, with one caveat: can CardDAV be used for Google? Evolution
itself uses the GData API. The client ID would be the same for each app
in this case, right?
I've looked at the EDS backend for UOA. It has the code which retrieves
the OAuth2 token. I could do something similar in SyncEvolution.
EDS does not seem to have the actual libaccounts backend. Where is that
maintained?
--
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.
7 years, 9 months
Re: [SyncEvolution] SyncEvolution + SSO + credentials
by Valluri, Amarnath
Hi,
I am working on gtk based UI for gSSO, It is about to ready, testing is going on.
I guess by this weekend, i can push the functional UI.
- Amarnath
________________________________________
From: Kanavin, Alexander
Sent: Friday, July 12, 2013 6:57 PM
To: Ohly, Patrick
Cc: SyncEvolution; ken(a)vandine.org; Laako, Jussi; Valluri, Amarnath
Subject: Re: SyncEvolution + SSO + credentials
On 07/12/2013 05:34 PM, Patrick Ohly wrote:
>> I think Google provides some defaults when registering clients.
>
> I was asking because it sounded like the value had to match what the
> actual OAuth2 implementation then uses.
Yes, but the redirect uri is again a part of account configuration info,
provided by the app to gsso. OAuth plugin uses what it gets from the app
and doesn't hardcode the uri.
> When using libaccounts-glib, where does the client key come from? Sounds
> to me like SyncEvolution would still need some kind of setting for
> "google-calendar" where that piece of information is stored.
libaccounts-glib is meant for public information that is not specific to
any client, so you need to store the client key inside your binary, or
read it from some secret file, or use gsso with a password plugin for
storing and retrieving the client id/key securely.
> Or are you saying that libaccounts-glib would store the key/value pairs
> that I described above, including SyncEvolution's own client key?
Yes, except the SyncEvo's client id and key.
> Any chance to get that fully-working example program soonish that we
> talked about? :-)
I'll start working on it early next week, but we also need a functional
gtk-based gsso UI component (where the browser magic happens). Amarnath,
do you have any idea about how long it's going to take?
Alex
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
7 years, 9 months
Re: [SyncEvolution] SyncEvolution + SSO + credentials
by Patrick Ohly
On Fri, 2013-07-12 at 17:00 +0300, Alexander Kanavin wrote:
> On 07/12/2013 03:54 PM, Patrick Ohly wrote:
> > What "redirect_uri" should be used when registering SyncEvolution?
>
> I think Google provides some defaults when registering clients.
I was asking because it sounded like the value had to match what the
actual OAuth2 implementation then uses.
> > 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.
>
> Or you could also use libaccounts-glib :)
When using libaccounts-glib, where does the client key come from? Sounds
to me like SyncEvolution would still need some kind of setting for
"google-calendar" where that piece of information is stored.
Or are you saying that libaccounts-glib would store the key/value pairs
that I described above, including SyncEvolution's own client key?
> > Does this all sound reasonable so far? Can someone explain how that'll
> > map to APIs and functionality in gSSO and UOA?
>
> I think it's all quite reasonable; you should start looking at
> libgsignon-glib to see specific APIs.
Any chance to get that fully-working example program soonish that we
talked about? :-)
--
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.
7 years, 9 months