I’m trying to add a caldav and carddav account, but when I do it says 403 forbidden. The auth data is correct (the owncloud and owncloud news apps work)
Please give detailed steps to reproduce, including exact version numbers and in best case a test account. I I guess it’s a server configuration issue because Owncloud 6 is known to work with DAVdroid.
All versions are the last ones (owncloud 6.0a and davdroid 0.5.3-alpha). I don’t know how to reproduce it 
Trying to connect to owncloud through caldav/carddav with other applications (browser and akonadi) it works and correctly fetches the data. But when I put the same data in davdroid it says 403 forbidden
The owncloud installation is a fresh one with all the default settings
Can you provide logcat output? Without detailed info, I can’t resolve this issue.
I’m trying having them from the hosting company (I’m running on a shared hosting and they don’t provide the ssl log from the web panel)
Meanwhile, does davdroid use the browser API when it tries to authenticate? I’m reading that the ROM I’m using has problems with it (and all the apps using it don’t work correctly). I’ve tried to connect from another Android device using the carddav-syn app and it works (I can’t try with with davdroid as it doesn’t support old Android versions 
)
p.s. happy holidays!
DAVdroid doesn’t use the browser API but the Apache HTTP library shipped with Android.
I’ve upgraded to the last mod version which is on the 3.4 kernel and the browser api works, but now when I try to create a new davdroid account it says error i/o connection went timeout
I don’t understand. Is the 403 Forbidden issue resolved?
If yes, please create a new issue with your problem with detailled instructions on how to reproduce the problem and, if possible, logcat output.
The 403 Forbidden issue does not seem to be resolved. At least not on the biggest Owncloud-hoster Arvixe where this problem can still be reproduced!
However, it seems to be a configuration issue of the hoster but if one of the biggest hosters has this problem then this should be fixed in DAVdroid!
To reproduce do the following:
Now add a new DAVdroid account on Android and enter the following credentials
Outcome: Unencrypted it’s working, but now try to connect via a secure connection via https and enter the following credentials:
Outcome: An error pops up saying Error message: “HTTP error: 403 Forbidden”
As I said: it seems to be a configuration issue of the hoster but if one of the biggest hosters has this problem then this should be fixed in DAVdroid!
And using an unencrypted connection via http is no option!
Greetings
egdd
Thanks for your report.
As I said: it seems to be a configuration issue of the hoster but if one of the biggest hosters has this problem then this should be fixed in DAVdroid!
Well, I assumed that DAVdroid works fine via https (http://davdroid.bitfire.at/specs) but on this hoster it does not. That’s why I guessed that the problem is host-specific. But of course I cannot confirm a hundred percent.
Be that as it may. I just provided steps reproduce this error because it occurred to me, too and this Issue here was labeled “need info”.
The old problem: “~” is not an allowed character in URLs. The lever that makes it (not) working is not HTTP/HTTPS but whether the URL contains a tilde or not.
Proof:
curl -v -X PROPFIND --user user:pw https://owncloud.arvixe.com/~user/remote.php/caldav returns 200 OKcurl -v -X PROPFIND --user user:pw https://owncloud.arvixe.com/%7euser/remote.php/caldav returns 403 ForbiddenSo, to fix the bug, please report to Arvixe that their server should understand properly encoded URLs (even it they say that tilde is allowed in URLs, servers should always understand the escaped form; this is the reason why DAVdroid always sends the encoded URLs when not sure). Can you please do that? You can mention this issue for reference.
For a workaround, you may use an own domain with an own SSL certificate so that you don’t have to use URLs with ~.
Hi, Thank you for letting us know. The customer has a ticket open with us (Arvixe) and we are assisting him through that. Regards.
So I’m closing this now. If there’s anything DAVdroid could do, please post here again.
Thank you for giving me these hints. It seems that the problem at Arvixe was related to the dot in their subdomain “http://[ChosenAtRegistration].owncloud.arvixe.com”. They were very kind to assist me and provided me something like “http:/[AssignedLater].arvixe.com”. And this way it also works with the SSL certificate. The guys at Arvixe’ support have been very helpful indeed.
So thank you for directing me in the right path for solving this thing. Maybe this thread helps other, too.
I have the same issue on arvixe. I’ve installed owncloud on my own shared server, after many tickets they said that they are not able to fix it, but instead they monkey patched the owncloud code adding a constant with my server url to the owncloud code. This is quite bad since it must be changed everytime owncloud is upgraded. I wonder if you may change your mind and fix it on the davdroid code instead, which would help all people using owncloud with arvixe
I wonder if you may change your mind and fix it on the davdroid code instead, which would help all people using owncloud with arvixe
It’s not a matter of my opinion. URLs must by definition not contain “~” and we had many issues when we used this character unescaped. The problem is that in both cases problems occur, so I’d like to stick with the standards-compliant solution.
The best solution would be that Arxive decodes URL correctly and converts %7e to tilde internally.
@rfc2822 That issue with ~ is fixed and if customers are having issues we need their information to assist them.
@xdmx please contact QA at Arvixe dot com and we can assist you. Thank you.
Arvixe team was very helpful. To the topic: They told me that not the tilde ("~") is the problem but the dot ("."), in other words “creating a subdomain of a subdomain, is what prevents the shared ssl from working”.
So for me the solution was that they offered me a subdomain in the form of “https://[MyOwnSubdomain].arvixe.com” and that works well with the SSL certificate. No code patching necessary.