Inf-IT DAV Clients

davclients@lists.inf-it.com

314 discussions

CalDavZAP Do Not Load Reminders Lists
by Aidan Montare 08 Aug '16

08 Aug '16

CalDavZAP is great for my personal needs, but loads a little slow with the number of collections I have (30+). I would like to set CalDavZAP to only load the Calendars, not the reminders (since most of the time I only need the Calendars portion). I have found the globalLoadedTodoCollections option in config.js. Is there a way to configure CalDavZAP to load no todo collections? The best workaround I have found is to just set it to load one collection. As a follow up question, is it possible to allow the user to load new collections after they login (i.e. those reminders lists I do not generally want to display)? For now I just created a second installation of CalDavZAP that is set to display all collections. -- Aidan Montare aidan(a)aidanmontare.net https://aidanmontare.net/ Legitimate emails from Aidan are signed using GPG. See https://aidanmontare.net/contact/ for details.

2 1

Configuration issue: multiple accounts
by Bastien Sevajol 01 Aug '16

01 Aug '16

Hi, I just sent this email to caldavzap(a)inf-it.com, but davclients(a)inf-it.com is maybe more appropriate ? Thank you for your CalDavZap application. I think is the only free full javascript caldav client on the web :) I have a problem with calendar configuration. I configure 3 calendars in globalAccountSettings, but only one is visible in interface. config.js globalAccountSettings is: > > var globalAccountSettings=[ > { > href: 'http://127.0.0.1:5232/user/3.ics/', > userAuth: > { > userName: 'bastien.sevajol(a)algoo.fr', > userPassword: 'bastien.sevajol(a)algoo.fr' > }, > timeOut: 90000, > lockTimeOut: 10000, > checkContentType: true, > settingsAccount: true, > delegation: true, > hrefLabel: 'http://127.0.0.1:5232/user/3.ics/', > forceReadOnly: null, > ignoreAlarms: false, > backgroundCalendars: [] > }, > { > href: 'http://127.0.0.1:5232/workspace/2.ics/', > userAuth: > { > userName: 'bastien.sevajol(a)algoo.fr', > userPassword: 'bastien.sevajol(a)algoo.fr' > }, > timeOut: 90000, > lockTimeOut: 10000, > checkContentType: true, > settingsAccount: true, > delegation: true, > hrefLabel: 'http://127.0.0.1:5232/workspace/2.ics/', > forceReadOnly: null, > ignoreAlarms: false, > backgroundCalendars: [] > }, > { > href: 'http://127.0.0.1:5232/workspace/1.ics/', > userAuth: > { > userName: 'bastien.sevajol(a)algoo.fr', > userPassword: 'bastien.sevajol(a)algoo.fr' > }, > timeOut: 90000, > lockTimeOut: 10000, > checkContentType: true, > settingsAccount: true, > delegation: true, > hrefLabel: 'http://127.0.0.1:5232/workspace/1.ics/', > forceReadOnly: null, > ignoreAlarms: false, > backgroundCalendars: [] > }, > ]; (Screenshot of UI (just one calendar listed)) Actually, 2 others calendars are loaded and in HTML DOM, but with style="display: none;". Do you know this issue ? Thank's very much, Bastien Sevajol.

2 8

External vs. Internal
by zyrixx 21 Jun '16

21 Jun '16

Hello, so far I can use with my CALDAVZAP either internal or external with my URL. If it is to function internally, must in the href my internal URL stand for external use that is only possible in the href with the external URL. Does this have to do with the topic Cross Domain and then the Apache configuration has to be changed? Best wishes Tom

2 2

Public or global calendar
by zyrixx 21 Jun '16

21 Jun '16

Hello and thanks for this great program that I use along with Baikal since yesterday. Is it possible, in addition to the Authorized Use of the respective user on integrate a global calendar for all users? I imagine it to be so: var globalNetworkCheckSettings={ href: 'https://myserver/calcard.php/principals/', hrefLabel: null, additionalResources: [], forceReadOnly: null, settingsAccount: true, timeOut: 90000, lockTimeOut: 10000, delegation: true, backgroundCalendars: true, ignoreAlarms: false }, href: 'https://myserver/caldav.php/public/default/', userAuth: { userName: 'Publicman', userPassword: 'PASSWORD' }, timeOut: 90000, lockTimeOut: 10000, checkContentType: true, settingsAccount: true, delegation: true, hrefLabel: null, forceReadOnly: null, ignoreAlarms: false, backgroundCalendars: [] }, That would be great! Best wishes Tom

2 4

Remove me from mailing list thanks
by Geordie 17 Jun '16

17 Jun '16

1 0

MacOS Yosemite
by Uwe Willenbacher 20 May '16

20 May '16

Hello there, I wonder if anybody is running CalDavZAP successfully on MacOS Yosemite. I looked into the readme files and the mailing list archive and found only a couple of emails from October 2014 related to this issue. Problem seems to be the “in good old Apple fashion” everything changed and the location and or implementation of certain services have either vanished or are being re-written and moved. In this case the only thing left in “/Applications/Server.app/Contents/ServerRoot/usr/share/caldavd/lib/python/” is “ServerFoundation” with an “__init__.py” script. The patch is looking for “/Applications/Server.app/Contents/ServerRoot/usr/share/caldavd/lib/python/twext/web2” which vanished☹ Has anybody been able to solve this problem? My goal is to have a user that is already logged into the server see his/her calendar online.. Thanks in advance for any help, - Uwe

2 1

Re: [Inf-IT DAVcl] Blank page,with Internet Explorer
by Colin Purcell 22 Apr '16

22 Apr '16

Sorry about the delay, but here's my follow-up, as promised. I'll break your reply down to the core questions/concerns, for brevity's sake. I think in light of basic auth, digest auth looks more like fort knox -bcrypt would be fort nox; MD5 (digest uses it exclusively https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#digest) is the cryptographic equivalent of a bridge made of straws (way too fast and not salted) -"The original author of the MD5 password hash algorithm has publicly declared his software end-of-life and is "no longer considered safe" to use on commercial websites." June 2012 http://www.zdnet.com/article/md5-password-scrambler-no-longer-safe/ (sources should be linked throughout the article) TLS only addresses "end-to-end" encryption, but does not protect you from host-related threats. -If this is truly your primary concern, you should be writing your own authentication mechanism to address the security gap (or forgo passwords http://www.cnet.com/news/google-security-exec-passwords-are-dead/). Digest's approach to only transfer and store hashes seems ideal, but it utilizes a weak hashing algorithm. Basic supports the strongest hashing algorithms, but decrypts the TLS packets before hashing and verifying the password. Basic is considered the "go to" because out of the two, stored MD5 passwords are a bigger surface for attack than user passwords stored in memory for fractions of a second (sys admins are legally bound, and you should be seriously considering other countermeasures if you think a hacker might be able to gain access to your system memory. See: SELinux). The number of ways to break TLS connections is growing -I'm not sure whether to say this statement is redundant or false; an updated system is really only vulnerable to zero-day exploits. While zero-days should be considered during planning, we're actually talking about a general security compromise with digest (even if it includes a shift in the attack vector), so I'm going to say this point is moot in the context of digest as a solution (and in light of what I've shared above). Are you trying to say that Digest Auth is "unnecessarily increasing complexity/server load"? -Yes. Especially because it actually has security drawbacks (like limiting the hashing algorithm you store passwords with). Other considerations -exploitable via a Man-in-the-Middle attack. https://tools.ietf.org/html/rfc2617 (refer to section 4.8) -though rfc2617 also added a number of security options, a number of them are purely optional (you'll want to read through the above link for more detail on which features this affects) -based on your concerns, you should really check out that cnet article and consider implementing soft-tokens in place of passwords. They're more secure, and in the event of a compromise, they're unique and disposable. Hopefully this is digestible (unintentional pun). I'll try to answer any other questions you have, but I'm not sure I'll have the time/energy for another email this long so you may have to keep it to a couple more straightforward questions. --- Colin Purcell | IT Administrator On 2016-04-05 5:59 am, Tobias Mueller wrote: > Hi. > > On Mo, 2016-04-04 at 19:07 -0400, Colin Purcell wrote: >> digest is widely accepted as laughably weak > Do you have any references for your claim? > > I think in light of basic auth, digest auth looks more like fort knox. > So it seems only logical to prefer digest auth over basic auth whenever > possible. InfCloud claims that it is not compatible, but I haven't > seen any instance of such an incompatibility. The documentation also > lacks pointers to said incompatibilities. > > My hypothesis is that such incompatibilities do not exist. In fact, > I'm using (admittedly an older version of) CalDAVMate successfully with > Firefox and Baikal configured to do digest auth. > > For now, it seems to me that digest auth is advised against without any > substantiation. I would like to understand why basic auth is preferred > over digest auth. > > >> and >> thus a generally unnecessary layer when the entire session >> (including >> the authentication process) is already secured via SSL or TLS. > Fair enough, but that's not the argument that InfCloud brought up. The > argument there seems to be "Lot of browsers have wrong or buggy digest > auth support (especially if used from JavaScript)". > > Also, I think it's wrong. I agree that TLS solves many problems. But > it doesn't solve all problems that digest auth addresses. > > TLS is not used for client authentication. Nobody does, unfortunately. > So TLS is only used for preventing someone on the wire to mess with > your packets. > > But there are more threats than that. You may not want your > credentials to leak to a curious sysadmin, anyone stealing the > credentials stored on the server, or a broken client implementation of > your protocol. And mind you, things tend to be more broken than we > think. The number of ways to break TLS connections is growing. > > So even if you think that TLS solves all of your problems, some people > find it valuable to have a second line of defence. But you recommend > against it with no good cause, from what I have understood so far. > > > >> I would compare Digest Authentication to requiring a second password >> for login > I think this comparison is very flawed. If only because with digest > auth, you don't leak your credentials in plain text to anyone who is > able to get their hands on your traffic. So the additional security is > very much unlike a second password. > >> you're much better off to increase the >> length of the original password (key length for our purposes) or >> explore other avenues of security that don't unnecessarily increase >> complexity/server load (one-time passwords maybe? The world is your >> oyster). > Are you trying to say that Digest Auth is "unnecessarily increasing > complexity/server load"? > > I agree with the sentiment of your example: It's about making the cost > of an attack much more expensive than defending against them. > > And this is exactly why I don't understand that digest auth is frowned > upon. From what I can tell it's well supported in both servers and > clients. It costs a round trip and a few hashes. Sure, that's much > more expensive than basic auth, but the attack is much much more > expensive. Unless you convince me that it's "laughably weak", I > maintain the proposition that digest auth provides more value than > basic auth. And I think it's very easy to see. Even when using TLS. > Combined with what I consider low cost (modulo the yet to see > incompatibilities which would weigh a lot), I don't see how you could > possibly conclude to advise against digest auth. > > >> >> If you're genuinely interested in the topic, I'd be happy to >> elaborate on anything unclear. > Looking forward to reading. > > Cheers, > Tobi

2 2

Re: [Inf-IT DAVcl] Blank page,with Internet Explorer
by Admin - Muskoka Auto Parts Limited 08 Apr '16

08 Apr '16

On 2016-04-05 5:59 AM, Tobias Mueller wrote: > I think in light of basic auth, digest auth looks more like fort knox. > So it seems only logical to prefer digest auth over basic auth > whenever possible. InfCloud claims that it is not compatible, but I > haven't seen any instance of such an incompatibility. The > documentation also lacks pointers to said incompatibilities. My > hypothesis is that such incompatibilities do not exist. In fact, I'm > using (admittedly an older version of) CalDAVMate successfully with > Firefox and Baikal configured to do digest auth. For now, it seems to > me that digest auth is advised against without any substantiation. I > would like to understand why basic auth is preferred over digest auth. Getting back to the OP (me :-) It doesn't work with Internet Explorer. Says so right there in the subject line. I'm *guessing* it's because of the digest auth issue the developer alludes to. You say you're using Firefox. It works for me when I'm using Firefox. So unless somebody has a fix that doesn't involve me swapping the basic auth, I'd consider it substantiated.

2 1

Formatted Name
by Jean-Philippe Garcia Ballester 06 Apr '16

06 Apr '16

Hello all, The “Formatted Name” field of contacts is not used. Our problem is that we have a very big addressbook, and all contacts only have Formatted Name (no Last Name nor First Name). Attached is a patch that adds a field named “Display Name”, as most carddav clients call it, that is displayed in the contact window and editable. It is also used by default in the contact list. Warning: it has not been extensively tested (and only with Davical as a server), but it seems to work well. It would be very interesting for us if it could be tested by more people and eventually included in an official release. Best regards, -- Jean-Philippe Garcia Ballester Demo-TIC

2 4

Fwd: Blank page,with Internet Explorer
by Admin - Muskoka Auto Parts Limited 04 Apr '16

04 Apr '16

A follow up thought. If the problem is definitely digest, it might be easier to create another virtual host and a separate baikal install set to basic auth for just the carddav. Then I could leave the caldav alone...

4 8

← Newer
1
...
5
6
7
8
9
10
11
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients