930541 - Special characters break CalDav authentification to Owncloud

Status: UNCONFIRMED

(Calendar :: Provider: CalDAV, defect)

Description

[Vincent]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911155223

Steps to reproduce:

Hello,

Today I created a new calendar into Owncloud. I wished to sync it with Thunderbird and Lightening plugin, and when I tried to login with a password containing those characters: ! @ €




Actual results:

The login failed. After a long time, I just realized that it's a common problem with escaping characters in password. I decided to try to change my password and now it works.


Expected results:

So I'm sure if the bug is your side or Owncloud one's, but you must investigate. The problem is exactly the same with the Thunderbird SoGo plugin to sync contacts through CardDav, and same solution.

Comment 1

[u422471]

Hi,

see https://github.com/owncloud/core/issues/7894 for some pointers why you shouldn't use such special chars in *DAV chars at all. Seems this leads to various issues like the seen here.

Comment 2

[Michael von Glasow]

Same here, trying to connect to DAViCal.

* Address book with CardBook add-on works.
* Both address book and calendar work from an Android device using DAVdroid.
* Calendar fails and keeps asking me for credentials over and over.

I have previously used Owncloud and had the same issue. Here I was able to resolve it by generating an access token for Calendar (which is used instead of the password and has only alphanumeric characters and hyphens).

Not using special characters in passwords reduces password security (smaller character set to choose from => fewer possible combinations for a given password length).

If the specs are ambiguous regarding encoding (resulting in different, incompatible implementations), there are a few options to resolve that:

* Make encoding configurable (user chooses password encoding)
* Probing (try all possible encodings until one works, then store it and use it from then on—caveat: if the server is configured to lock the user out after a certain number of failed password attempts, this may trigger it)
* Maintain a list of CalDAV servers and encodings they support, guess the server software (e.g. by inferring it from the URL, possibly also response headers)
* Or a combination of these (ask user to choose an encoding but offer autodetection as an option, i.e. first try the list of known encodings, then probe)

Comment 3

[Michael von Glasow]

I examined the requests on the Developer Console. The authentication data sent by CardBook and Calendar differ, despite the password being the same—a clear indication of different (or possibly incorrect) encoding.