Horde sync fails with error 401 Unauthorized since DAVdroid 0.8.1


  • developer

    So, if the credentials are sent correctly and Horde returns 401, it must be a problem with Horde?



  • But nothing changed with Horde, so that seems strange ad well. Maybe I will install the previous version and see if the authentication works differently there (e. g. different encoding of the @ sign or something of the sort)
    Am 13.07.2015 12:29 schrieb rfc2822 notifications@github.com:So, if the credentials are sent correctly and Horde returns 401, it must be a problem with Horde?

    —Reply to this email directly or view it on GitHub.


  • developer

    The @ sign is in the ASCII range, so it shouldn't be encoded.

    May it's somehow related to the Cookie support introduced with DAVdroid/0.8.1? Cookies are now stored for the sync process so that Horde can detect it's one "session".



  • If you could give me a build with cookies disabled/optional (signed via
    Fdroid), I could test that out; but not sure if that is possible. Any other
    ideas to check this?

    rfc2822 notifications@github.com schrieb am Mo., 13. Juli 2015 14:37:

    The @ sign is in the ASCII range, so it shouldn't be encoded.

    May it's somehow related to the Cookie support introduced with
    DAVdroid/0.8.1? Cookies are now stored for the sync process so that Horde
    can detect it's one "session".


    Reply to this email directly or view it on GitHub
    https://github.com/bitfireAT/davdroid/issues/577#issuecomment-120913289.



  • DavDroid would have to release a new version to get a build signed by Fdroid.

    On 13 July 2015 15:28:32 CEST, Natanji notifications@github.com wrote:

    If you could give me a build with cookies disabled/optional (signed via
    Fdroid), I could test that out; but not sure if that is possible. Any
    other
    ideas to check this?

    rfc2822 notifications@github.com schrieb am Mo., 13. Juli 2015 14:37:

    The @ sign is in the ASCII range, so it shouldn't be encoded.

    May it's somehow related to the Cookie support introduced with
    DAVdroid/0.8.1? Cookies are now stored for the sync process so that
    Horde
    can detect it's one "session".


    Reply to this email directly or view it on GitHub

    https://github.com/bitfireAT/davdroid/issues/577#issuecomment-120913289.


    Reply to this email directly or view it on GitHub:
    https://github.com/bitfireAT/davdroid/issues/577#issuecomment-120926192

    --
    Sent from my phone. Please excuse my brevity.



  • Well, I'm in a bit of a bad situation right now. The problem is that I have no access to the Horde server, can't provide logs there, and therefore can't file a bug report in Horde. Besides, convincing the Horde developers that the bug is at their side will be hard when essentially I will tell them "DAVdroid changed something and now it doesn't work with Horde anymore".

    Firstly, I would like someone who runs their own Horde server, like @t-brink, to file that bug report with as much info as possible so this gets fixed.

    In the meantime, users of DAVdroid should have a better option than just not using DAVdroid anymore, correct? Therefore I propose that either the DAVdroid developers try to reproduce this problem with Horde and find a workaround, or that the new auth method which seems the likely cause is given an advanced "disable" option.

    Because really, the only alternative to any user of Horde at the moment is uninstalling DAVdroid completely (losing any changed calendar/contact info in the meantime on the phone) and then installing 0.8, and staying at 0.8 indefinitely until Horde fixes this bug. Which is probably going to take a while.

    I know this situation sucks, but I believe DAVdroid should not introduce changes that completely break compatibility with one of the huge server softwares typically used with it. This is a critical bug.

    I also politely ask to remove the "need info" label, since all the info that I can provide was already provided. I will try to be of any help I can, but I don't know what to do at this point except switching to 0.8 and never updating DAVdroid again.


  • developer

    Besides, convincing the Horde developers that the bug is at their side will be hard when essentially I will tell them "DAVdroid changed something and now it doesn't work with Horde anymore".

    I don't say that the bug is on the Horde side. I just can't see any misbehaviour on DAVdroid's side when the URL and credentials are correct and Horde says 401.

    The "need info" tag is there because I don't know what to do. There's no bug identified yet. Do you have any suggestions on how to detect the possible bug in DAVdroid?


  • developer

    Just installed Horde 5.3.0 from Debian 8.0 and everything works fine…

    http-outgoing-15 >> "REPORT /horde/rpc.php/calendars/test/calendar~uw2x0m8A3cFSh9k-zctX-A1/ HTTP/1.1[\r][\n]"
    http-outgoing-15 >> "Content-Type: text/xml; charset=UTF-8[\r][\n]"
    http-outgoing-15 >> "Accept: text/xml[\r][\n]"
    http-outgoing-15 >> "Depth: 1[\r][\n]"
    http-outgoing-15 >> "Content-Length: 260[\r][\n]"
    http-outgoing-15 >> "Host: debian-test[\r][\n]"
    http-outgoing-15 >> "Connection: Keep-Alive[\r][\n]"
    http-outgoing-15 >> "User-Agent: DAVdroid/0.8.1[\r][\n]"
    http-outgoing-15 >> "Cookie: Horde=7lubh9svrqfokhnqfeh4iprem0[\r][\n]"
    http-outgoing-15 >> "Cookie2: $Version=1[\r][\n]"
    http-outgoing-15 >> "Authorization: Basic dGVzdDp0ZXN0[\r][\n]"
    http-outgoing-15 >> "[\r][\n]"
    http-outgoing-15 >> "<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns="DAV:">[\n]"
    http-outgoing-15 >> "   <C:filter>[\n]"
    http-outgoing-15 >> "      <C:comp-filter name="VCALENDAR">[\n]"
    http-outgoing-15 >> "         <C:comp-filter name="VEVENT"/>[\n]"
    http-outgoing-15 >> "      </C:comp-filter>[\n]"
    http-outgoing-15 >> "   </C:filter>[\n]"
    http-outgoing-15 >> "   <prop>[\n]"
    http-outgoing-15 >> "      <getetag/>[\n]"
    http-outgoing-15 >> "   </prop>[\n]"
    http-outgoing-15 >> "</C:calendar-query>"
    http-outgoing-15 << "HTTP/1.1 207 Multi-Status[\r][\n]"
    http-outgoing-15 << "Date: Fri, 17 Jul 2015 22:13:28 GMT[\r][\n]"
    http-outgoing-15 << "Server: Apache/2.4.10 (Debian)[\r][\n]"
    http-outgoing-15 << "Expires: Thu, 19 Nov 1981 08:52:00 GMT[\r][\n]"
    http-outgoing-15 << "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0[\r][\n]"
    http-outgoing-15 << "Pragma: no-cache[\r][\n]"
    http-outgoing-15 << "Set-Cookie: horde_secret_key=7lubh9svrqfokhnqfeh4iprem0; path=/; domain=debian-test; httponly[\r][\n]"
    http-outgoing-15 << "Vary: Brief,Prefer,Accept-Encoding[\r][\n]"
    http-outgoing-15 << "Content-Length: 529[\r][\n]"
    http-outgoing-15 << "Keep-Alive: timeout=5, max=100[\r][\n]"
    http-outgoing-15 << "Connection: Keep-Alive[\r][\n]"
    http-outgoing-15 << "Content-Type: application/xml; charset=utf-8[\r][\n]"
    http-outgoing-15 << "[\r][\n]"
    

    I need more information.

    • Which authentication type do you use?
    • Does it happen when you add only address books/calendars without entries, too?
    • If no, can you provide a contact/event that reproduces the issue?
    • Any other ideas how this can be reproduced and/or diagnosed?

  • developer

    Any news on this?


  • developer

    Closing this for now as repeated Horde testing doesn't show any problems here.

    If you have any news on this, please post here and I'll re-open.



  • I had this problem, too. For those interested: As far as I understand, it had something to do with multiple connections when synchronizing multiple calendars. This seems to be a Horde bug, actually. Maybe a change in the sync strategy caused the Horde bug to become apparent?
    Here is the ticket: http://bugs.horde.org/ticket/13449
    The Horde "No password provided" log entry is misleading and completely unrelated to the 401, by the way.

    tl;dr: Update Horde to at least 5.2.3


  • developer

    Ok, so this seems to be a third-party issue. Closing it now.