Inf-IT DAV Clients

davclients@lists.inf-it.com

313 discussions

Problem with crossDomain-setup
by Thomas W. 26 Mar '13

26 Mar '13

Hi, regarding the documentation I have to use the crossDomain attribute, if I want to use a caldavzap installation with the URL "https://xxx.aaa.com:443/calclient", which should use a Davical installation at URL "https://yyy.aaa.com:443/". I set the crossDomain attribute to "true", but the installation is not working. The Apache2 logging says, that there is an request to URL "https://xxx.aaa.com:443/caldav.php/", but this is wrong. What is the correct setup for this scenario? Must I use the hrefLabel attribute or something else? I also tried to modify the Apache2 Vhost config for the Davical vhost (generic allow rule), but this is not working either. Any ideas? Thanks and kind regards, Thomas

2 2

Re: [Inf-IT DAVcl] Strange behaviour
by Andrej Lezo 22 Mar '13

22 Mar '13

Hello Simon It is normal behaviour because we are using PROPATCH property for saving user settings. The request is launched with every resource synchronization. So we need support for additional methods. Best regards, Andrej Lezo Simon <caldavzap(a)svswift.de> napísal: >Hello Jan, > >I now took a look in the logs: > >When opening caldavzap I get the following: > >ROPFIND http://server/SOGo/dav/user/Calendar/ 207 Multi-Status 74ms > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus xmlns:a="http://apple.com/ns/ical/" >xmlns:D="DAV:"><D:response><D:href>/SOGo/dav/user/Calendar/</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><D:read/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><D:unbind/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege></D:current-user-privilege-set><D:displayname>Calendar</D:displayname><D:resourcetype><D:collection/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.ics</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.xml</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal/</D:href><D:propstat><D:status>HTTP/1.1 >200 >OK</D:status><D:prop><a:calendar-color>#84BC34FF</a:calendar-color><D:current-user-privilege-set >xmlns:n2="urn:inverse:params:xml:ns:inverse-dav" xmlns:D="DAV:" >xmlns:n1="urn:ietf:params:xml:ns:caldav"><D:privilege><D:read/></D:privilege><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><n1:read-free-busy/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><n1:schedule/></D:privilege><D:privilege><n1:schedule-post/></D:privilege><D:privilege><n1:schedule-post-vevent/></D:privilege><D:privilege><n1:schedule-post-vtodo/></D:privilege><D:privilege><n1:schedule-post-vjournal/></D:privilege><D:privilege><n1:schedule-post-vfreebusy/></D:privilege><D:privilege><n1:schedule-deliver/></D:privilege><D:privilege><n1:schedule-deliver-vevent/></D:privilege><D:privilege><n1:schedule-deliver-vtodo/></D:privilege><D:privilege><n1:schedule-deliver-vjournal/></D:privilege><D:privilege><n1:schedule-deliver-vfreebusy/></D:privilege><D:privilege><n1:schedule-respond/></D:privilege><D:privilege><n1:schedule-respond-vevent/></D:privilege><D:privilege><n1:schedule-respond-vtodo/></D:privilege><D:privilege><D:unbind/></D:privil >ege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:read-acl/></D:privilege><D:privilege><D:write-acl/></D:privilege><D:privilege><n2:admin/></D:privilege><D:privilege><D:all/></D:privilege></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype><D:collection/><calendar >xmlns="urn:ietf:params:xml:ns:caldav"/><vevent-collection >xmlns="http://groupdav.org/"/><vtodo-collection >xmlns="http://groupdav.org/"/><schedule-outbox >xmlns="urn:ietf:params:xml:ns:caldav"/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><D:sync-token/></D:prop></D:propstat></D:response></D:multistatus> > > >REPORT http://server/SOGo/dav/user/Calendar/personal/ 207 Multi-Status > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus >xmlns:D="DAV:"><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/6d026dd6044076dfde4ed7ecbedeec887b0df320de9ccd95f9f7469aae99cd17.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000002"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/c35bf93529a8a22cb079dc4d924ac359c477d2f0d60fcc88208b9bb02a14a658.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000001"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-token>1363922134</D:sync-token></D:multistatus> > >The .ics-file looks as follows: >BEGIN:VCALENDAR >VERSION:2.0 >BEGIN:VEVENT >CREATED:20130322T031033Z >LAST-MODIFIED:20130322T031532Z >DTSTAMP:20130322T031532Z >UID:b583diub-4e32-ia2p-ljmd-2yak0ufcgl5g >SUMMARY:Test3 >TRANSP:OPAQUE >CLASS:PUBLIC >DTSTART;TZID=Europe/Berlin:20130322T090000 >DTEND;TZID=Europe/Berlin:20130322T100000 >END:VEVENT >END:VCALENDAR > > >Right after the next REPORT I get the following: > >PROPPATCH http://server/SOGo/dav/user/Calendar/personal/ 403 Forbidden ><?xml version="1.0" encoding="ISO-8859-1"?> ><html xmlns="http://www.w3.org/1999/xhtml"> ><body><h3>An error occurred during object publishing</h3><p>Property >'{http://inf-it.com/ns/cal/}cal-settings' cannot be set.</p></body> ></html> > > >Yours, >Simon > >Am 06.03.2013 01:58, schrieb Ján Máté: >> Hi Simon, >> >> On Mar 6, 2013, at 1:51 AM, Simon <caldavzap(a)svswift.de> wrote: >> >>> Hey Jan, >>> >>> just tell when and how I can help (with logs or an account etc.). >>> So far: Seems really good! >>> If you are redoing the interface, could you make it so that entrys have a default starting hour (p.ex. next full hour) and an end-date which is starting hour+1 (even if one changes the starting hour). >> >> use double-click on the hour fields, and you will get: >> - the current time as "start time" and >> - current time+1 hour as "end time" (if the start and end dates are the same) or >> - the same "end time" as "start time" (if the end date is greater than start date) >> >> You can also create events using mouse (click, drag and release) and the dates/times will be predefined :-) >> >> >> JM >> >>> >>> I really like the fact that CalDAVzap uses the predefined colors from the server. >>> >>> Simon >>> >>> Am 06.03.2013 01:42, schrieb Ján Máté: >>>> Hi Simon, >>>> >>>> CalDavZAP is currently tested ONLY with DAViCal. Support for more servers will come in future - I hope in next 2-3 months (currently we are working on completely new interface for ToDo and minor bug fixes). >>>> >>>> >>>> JM >>>> >>>> >>>> On Mar 6, 2013, at 1:35 AM, Simon <caldavzap(a)svswift.de> wrote: >>>> >>>>> Hello from Passau, >>>>> >>>>> I have setup CalDAVzap with SOGo. This is working partly. >>>>> When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. >>>>> >>>>> However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. >>>>> >>>>> It seems like CalDAVzap is failing to load those entries from SOGo. >>>>> In the SOGo-Logs I see PROPFIND and REPORT. >>>>> >>>>> Any help appreciated. >>>>> >>>>> Simon >>>>> >>>> >>> >> >

3 3

Strange behaviour
by Simon 22 Mar '13

22 Mar '13

Hello from Passau, I have setup CalDAVzap with SOGo. This is working partly. When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. It seems like CalDAVzap is failing to load those entries from SOGo. In the SOGo-Logs I see PROPFIND and REPORT. Any help appreciated. Simon

2 4

Custom fields?
by Sven Anders 21 Mar '13

21 Mar '13

Hello! Is it possible to configure custom fields in the clients? We want to build a company wide addressbook and we need a customer number/id. I think something like would be nice: custom_fields = [ {name:'Customer Number', id:'X-CustomerNumber' }, ... ]; Regards Sven Anders -- Sven Anders <anders(a)anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin

2 1

About v0.11rc1
by Attila Asztalos 14 Mar '13

14 Mar '13

Hi, a few things I encountered / remembered just now (currently with 0.11rc1): - At the periodic sync update (the default 60 seconds for me) the entire webpage goes void of data (the frames are still there, but address books and contacts disappear) for a few seconds, then all goes back to normal. However, it does jump back to the first contact in the address book and if I was editing a contact, the light-grey "edit mode" of the list persists, so I cannot click on other contacts unless I either log in and back out or click "edit" on the displayed contact then cancel. If there was unsaved data in the edited contact it is of course lost after this. There are no error messages in the console. I don't remember this happening before - CalDavZAP for instance still syncs very nicely in the background, all I see is the little rotating symbol. - You might want to include special Romanian chars U+015E, U+015F (s with cedilla) and U+0162, U+0163 (t with cedilla) in the sort and search alphabet strings at letter 's' and 't' respectively - I can do it in my own config but I guess it doesn't hurt to have them there by default. You might also want to include U+218, U+219 (s with comma) and U+21A, U+21B (t with comma) versions too - only one of these two version is actually supposed to exist, but which one is the correct one is a rather messy affair - interested parties can read all about it at [1] (TL;DR: cedilla is the widely supported and used one, comma is supposed to be the correct one). - Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that. Regards, - Attila [1] - http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C… [2] - http://en.wikipedia.org/wiki/Mailing_address_format_by_country#Romania [3] - http://www.posta-romana.ro/posta-romana/produse-si-servicii/Personal_subpag…

2 5

CardDavMATE 0.11rc1
by Ján Máté 13 Mar '13

13 Mar '13

Hi everybody, CardDavMATE 0.11rc1 is available at: http://www.inf-it.com/CardDavMATE_0.11rc1.zip with: - **MAJOR** performence enhancements - support for photo editing by click to the "photo box" - and many other fixes/imporovements: http://www.inf-it.com/carddavmate-next/changelog.txt demo: http://www.inf-it.com/carddavmate-next/ Much thanks for your feedback! JM

1 0

Re: vCard files
by Ján Máté 07 Mar '13

07 Mar '13

Atilla, thanks for testing the patch - here is the more optimised version + one additional fix for the PHOTO attribute: http://www.inf-it.com/fixes/data_process.js for everybody who experience the same problem with duplicate IM values or have a problem with missing photos, use the quick fix above (replace the data_process.js in CardDavMATE) ... or wait for the next version ... JM On Mar 6, 2013, at 9:29 PM, Attila Asztalos <attila.asztalos(a)gmail.com> wrote: > Hi Ján, > > Yes it does fix the duplication. Thank you. In the long run, you might want to consider parsing the X-SKYPE key too though - if I understand correctly, right now it wouldn't even show up if there were no IMPP duplicate of it in the vCard (this does not affect of course software that already does store skype IDs in both formats). > > Regards, > - Attila

1 0

regarding merging of IMPP data
by Attila Asztalos 06 Mar '13

06 Mar '13

Hi, I just noticed that something funny is going on with the IM ID data of my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so: X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id While it certainly can be argued that this is not exactly good practice (RFC4770 that defines the IMPP syntax says nothing about allowing or prohibiting the alternative notation in parallel - strictly speaking CardDavMate being entitled to interpret this as FOUR individual IDs), I think we can safely say it's reasonable to merge any number of instances of the same specific protocol AND same exact ID to a single one when presenting it to the user (reducing the above to only two IDs). Especially since this is already happening with Skype - but not with Yahoo. Could this be implemented as proposed? Regards, Attila

2 2

DAV clients vs. Chrome vs. Firefox
by Attila Asztalos 26 Feb '13

26 Feb '13

Hi all, I'm fighting with this stuff for over a week now and I have just about lost the will to live - there has to be something about my config but I have no idea what, and frankly it's a bit strange anyway: I managed to get both caldav and carddav running - but only in Chrome. So, here's the long version... - as mentioned earlier, I'm running a Baikal 0.2.4 server on top of Apache 2.2.22 with PHP 5.3.21 on a WinXP SP2 box. The Baikal folder sits inside the Apache htdocs folder, and is designated as "document root" (so "/" = "/htdocs/baikal"). The files of CalDavZap and CardDavMate are each sitting in their own "caldav" and "carddav" folders inside /htdocs/baikal/ respectively (I've briefly tried playing with other setups using virtual hosts, but even though those did work fine both with my phone and the [1] PHP test tool, I could never get either CalDavZap or CardDavMate to even authenticate so I dropped that - no virtual hosts are configured currently - that is not the issue at hand). - all this is running locally on the same Windows box I'm testing it from, currently designated as "dav.home.lan"; the port in use is the standard 80; the clients are accessed as "dav.home.lan/carddav/" and "dav.home.lan/caldav/"; the Baikal scripts are (as per default) "card.php" and "cal.php". - the browsers tested were Chrome 26.0.1410.12 beta-m and Firefox 18.0.2 - between each test and the next browsers had their caches cleared, Apache was restarted. - considering it isn't quite clear whether the Baikal URIs are supposed to end in "calendars" / "addressbooks" or "principals", I've tried both ways - neither was a complete success. Results were as follows (for brevity, accesses to inf-it are not listed): - Carddav, href: 'http://dav.home.lan/card.php/principals/' : Chrome works fine, Firefox apparently logs into an "empty session" (looks normal but all data is missing, there is no account logged in) - in fact, the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 401 ...I suppose Firefox is expected here to retry with a digest auth to the rejected basic one (as it did at line 2 after line 1), but it never does. - Carddav, href: 'http://dav.home.lan/card.php/addressbooks/' : Chrome works fine, Firefox works fine - this time, the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 207 REPORT http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 403 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 207 REPORT http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 207 etc... - Caldav, href: 'http://dav.home.lan/cal.php/principals/' : Chrome works fine, Firefox fails to log in (comes back to login prompt) then if login button is pressed again, appears to log in to an "empty session" (looks normal but all data is missing, there is no account logged in) - the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 401 (...nothing happens then I press "login" again...) GET http://dav.home.lan/caldav/cache.manifest with reply 200 GET http://dav.home.lan/caldav/ with reply none (not modified) GET http://dav.home.lan/caldav/cache.manifest with reply 200 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 401 ...then nothing happens - no digest auth retry. In the error console there are two errors for the two attempts: Error: [netCheckAndCreateConfiguration: 'http://dav.home.lan/cal.php/principals/'] code: '401' (from webdav_protocol.js 138) Error: [CalDAVnetLoadABResource: 'http://myuser@dav.home.lan'] code: '401' (from webdav_protocol.js 1040) - Caldav, href: 'http://dav.home.lan/cal.php/calendars/' : Chrome gets stuck with "Loading Resource List"... PROPFIND dav.home.lan/cal.php/calendars/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/ with reply 207 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND dav.home.lan/ with reply 200 ...which can't be right: without either "cal.php" or "card.php" in the path, all that's returned is "Baikal is running OK" and I'm pretty sure caldavzap can't process that. The error console shows nothing. ...while Firefox gets stuck exactly the same way, at exactly the same spot (no errors in the console): PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/ with reply 200 On all tries the only href variable set was "globalNetworkCheckSettings"; "globalUseJqueryAuth" was set to true; "crossDomain" was set to null, reported always as "false". Disabling all add-ons in Firefox made no difference. The problem is I normally use Firefox, not Chrome, and anyway, this is bizarre. Any idea what the heck is going on here...? If any further specific log details are needed, please let me know. Best regards and sorry for the "wall of text", - Attila [1] - https://github.com/graviox/CardDAV-PHP

2 3

CalDavZAP 0.8.1.1 released
by Ján Máté 25 Feb '13

25 Feb '13

Hi everybody, CalDavZAP 0.8.1.1 released - BIG thanks for your bug reports! http://www.inf-it.com/CalDavZAP_0.8.1.1.zip (no configuration changes, so you can use your config.js from 0.8.1) here are the patches from previous versions (for simpler upgrade): 0.8.1 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1-0.8.1.1.diff 0.8.1.1rc1 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1.1rc1-0.8.1.1.diff 0.8.1.1rc2 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1.1rc2-0.8.1.1.diff As usually, do not forget to execute cache_update.sh after you apply the patch! JM

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients