Problems Publishing Calendars to webdav server with Maverick's Calendar

Question

Level 1

20 points

Problems Publishing Calendars to webdav server with Maverick's Calendar

I have been trying to troubleshoot an issue I am having with Maverick's Calendar publishing to a Webdav server. I started another thread about this some time ago but never received a response, I was hoping that a software update or something would eventually fix the problem but it is still happening even with 10.9.2.

Basically, if I try to publish a calendar to a Webdav server it will simply not authenticate if there are certain characters in the password. For instance, a password of "passw0rd!" will authenticate while "passw0rd@" will not. Certain "special" characters just seem to not work and the @ symbol is one of them. This started with Mavericks, I have been successfully publishing calendars to the same Webdav server with no issues on machines running 10.4, 10.5, 10.6, 10.7 and 10.8 using the same user names and passwords that are failing in 10.9.

What I find very strange is that if I "Connect to Server" from the Finder's Go Menu and connect to the same Webdav server there it will authenticate and connect using the same usernames and passwords that fail to authenticate from the Calendar application. This leads me to believe that the problem lies in the Maverick's calendar application.

I have many users that I need to update to Mavericks but I don't want to have to change everyone's password to do so and I need to be able to publish calendars to a Webdav server. Has anyone else run into this? If so did you find any way to address the issue?

Thanks in advance.

Posted on Feb 25, 2014 3:04 PM

Reply

Answer 1

roarkh Author

Level 1

20 points

Apr 2, 2014 11:51 AM in response to roarkh

I am still having problems publishing calendars to two different WebDAV servers from the Mavericks calendar application (tested from mulitple workstations running Mavericks). I thought I would respond to this post in hopes of bringing it some more attention and to update it with a list of the special characters I have found that work and those that do not. Basically, if a password contains letters, numbers and any of the following characters it will work just fine...

! $ & * ( ) - _ = + ; ' , . ~

If a password contains any of the following characters the calendar can not be published to a WebDAV server...

@ # % ^ [ ] { } \ | : " < > / ? `

One of the servers I am testing publishing to is a Synology NAS device. It supports both WebDAV and CalDAV connections. I can use the same user name and password to connect to a CalDAV calendar account that fails when publishing an On My Mac calendar to WebDAV. Also, I can connect to the WebDAV folder using "Connect to Server..." just fine. The only place I am having problems with passwords in when publishing an On My Mac calendar to a WebDAV server. I have been able to do it (and still can) publish On My Mac calendars to the same WebDAV folder from 10.6, 10.7 and 10.8 clients.

I have lots of users that use special characters in their password and I really don't want to have to make them all change their passwords so it would be really nice to find a resolution to this issue. If anyone has any ideas I would appreciate hearing them.

Thank you.

Reply

Answer 2

Apr 2, 2014 10:04 PM in response to roarkh

Thankyou roarkh for your great research into this problem. I had the same issue: published fine in Lion and MLion then failed in Mavericks. The exact error I had was:

There was an unexpected error with the request (domain kCFErrorDomainCFNetwork / error 200).

I changed the user's password since it contained a % character and now publishing is working again. And, I agree the issue is with Mavericks Calendar because I could log into the server using FTP using the old password without a problem. Changing the password is an OK work around for me -- I only have one user publishing.

Thanks again,

Bob

Reply

Answer 3

Apr 9, 2014 7:26 AM in response to BobInBlanco

It appears that Apple has decided to enforce RFC1738 in Mavericks calendar which excludes the characters you found from user names and passwords. The servers appear to still be using RFC959 (or something similar) which allows any ASCII character in the password.

Reply

Answer 4

roarkh Author

Level 1

20 points

Apr 9, 2014 7:56 AM in response to BobInBlanco

That is an interesting find. I have not read through the entire RFC yet but it seems to me that this is a huge problem. For one thing, fewer available characters in a password makes it less secure. Also, I am sure I am not the only one that is using an Open Directory or Active Directory server for authentication, it does not make sense to me for password requirements for one service to be different than password requirements for another service. As it is this will force me to either stop using WebDAV entirely or force about 100 of my users to pick a new password.

Our local Apple reseller contacted Apple tech support regarding this on our behalf and at least the technician he talked to apparently was not even aware of this issue. Have you found an official Apple publication that explains the situation? If so can you point me in the direction of it?

Thank you for your comments, I really appreciate it.

Reply

Answer 5

roarkh Author

Level 1

20 points

Apr 9, 2014 8:47 AM in response to BobInBlanco

I found this information directly out of the RFC you mentioned...

--- From the RFC ---

Unsafe:

Characters can be unsafe for a number of reasons. The space

character is unsafe because significant spaces may disappear and

insignificant spaces may be introduced when URLs are transcribed or

typeset or subjected to the treatment of word-processing programs.

The characters "<" and ">" are unsafe because they are used as the

delimiters around URLs in free text; the quote mark (""") is used to

delimit URLs in some systems. The character "#" is unsafe and should

always be encoded because it is used in World Wide Web and in other

systems to delimit a URL from a fragment/anchor identifier that might

follow it. The character "%" is unsafe because it is used for

encodings of other characters. Other characters are unsafe because

gateways and other transport agents are known to sometimes modify

such characters. These characters are "{", "}", "|", "\", "^", "~",

"[", "]", and "`".

All unsafe characters must always be encoded within a URL. For

example, the character "#" must be encoded within URLs even in

systems that do not normally deal with fragment or anchor

identifiers, so that if the URL is copied into another system that

does use them, it will not be necessary to change the URL encoding."

--- End quote from RFC ---

The characters that are listed do match the ones I found that don't work so I definitely think you are on the right track. However, the FAQ does not say that the characters can not be used, just that they must be "encoded within a URL" so I still wonder if this is not an indication that there is a bug in the Maverick's calendar application.

Thanks again for your research into this.

Reply

Answer 6

Apr 9, 2014 9:47 AM in response to roarkh

I have found nothing official from Apple. Your research jogged a memory of a project I worked on a few years ago that included validating URLs. In section 5 of the RFC, "uchar" is stated as valid which includes an escape for any character ( use %5C for \ ) but that would only work if the server complies with the RFC and Apple uses the escape for encoding the password. I have not tested that. Sending the password as part of the URL is shown as optional in the RFC (part of "login") and Apple may have started doing that instead of waiting for a password prompt where the same restrictions would not apply.

My opinion is that it is only a bug if Apple does not use the escape for the excluded characters. But if they are using the escape and the server does not recognize it, then the bug is on the server side. Either way it is not consistent since "Connect to Server" from the Finder's Go menu behaves differently as you mentioned in your original post.

Reply

Answer 7

Mar 4, 2015 12:16 PM in response to roarkh

I can also confirm the problem with publishing calenders and 10.9.5. I had the character "<" in the password and I had to change it (no problem, only 2 users).

I also found out, that it's possible to subscribe to a calender on a WebDAV Server with a password containing "<" .... so it seems to be a problem with publishing only .. looks really like a bug.

Does anyone know if this problem still exists in 10.10.x?

Reply