During setup check for multiple hosts, path, users



  • Hi,

    I reworked the getCurrentUserPrincipal() in DavResourceFinder to be able to check for a list of domains, path, and users.
    This should fix issues like #465 and #439.

    I hope this satisfies you quality requirements :-)
    If not, I am willing to improve...



  • Heyho,

    I tried the proposed change and it kind of seems to work. It actually requests the given path before defaulting to listing the users directory. However DAVdroid still does not provide the expected shared calendars/contacts in my setup (radicale). I will report back soon with more verbose dumps.

    I also noted a part in the patch which could be done a little better. I also checked the rest of the patch and to me it looks fine, but I am by far no java expert…



  • Ok, I did a TCP dump of my testcase today with this pull request from @jochen314. I know it's against 8.0 and not 8.1 but a rebase should not be too hard.

    Now to the dump: The problem I see (I don't know DAV very well unfortunately), is that DAVdroid only requests the current-user-principal in the first request, but does not continue to query the /ANONYMIZED_SHARED_FOLDER/ with a correct PROPFIND in the next message.

    A colleague tested our radicale server setup with his CalDAV Sync and CardDAV Sync and everything worked perfectly for him.

    I hope this information/dump helps to finally fix #439 and also #249. If you need more info, let me know.



  • We have to make our requirements clear here.
    The code currently tries to be as close to <a href="https://tools.ietf.org/html/rfc6764">rfc 6764</a> as possible. And thsi rfc describes, how a client should discover the current user principal.

    The problem arises, when a full qualified url with a path is specified.
    There a 2 possible ways to handle this:

    1. use the path as a starting point for the current user principal discovery as described in the rfc
    2. use the path as directly as a calendar or address book, or try to find calendars and address books contained under the given url.

    One could argue, that a 'well behaved' server would announce all calendars/address books, that a you has acess to, using the PROPFIND for the current user principal and therefor the second option should not be needed....



  • I rebased ontop of v0.8.1



  • Ok, the current user principal discovery works fine for me, so my issue (not respecting the given path when searching for resources, before trying the user principal) might be out of scope for this pull request.

    My loop fix/change should still be valid as explained in the inlined comment from the first patch version.



  • Let's try this:
    If an explicit URL is given (no mailto: ), then we first check, if the URL points to a calendar or an address-book. If yes, we add it to the possible calendars/address-books.
    Then continue the normal processing.
    I committed this change to the branch.
    Please check, if this is a solution for your issue @schachmat



  • I did some more rework on the pull request in the hope, that is is easier to understand.
    There is probably still room for improvement on the documentation, please give me a hint and I will try my best to further improve.
    I also rebased onto the current master changes.


  • developer

    Thanks. Your patch is very welcome and I will take time to integrate it, but it will still take a while.



  • Heyho @jochen314,

    sorry for the delay, I was a little busy over the last weeks. I just tested your latest version and can confirm that shared resources in the URL are working.

    However, I can only put in one ressource, e.g. server.tld:port/shared/calendar.ics/. Then this calendar can be selected for events and tasks (as well as all the ones from the current user principal). Using server.tld:port/shared/ as an url only returns the users ressources, so if I want to use multiple shared ressources (even from the same "directory"), I have to set up multiple davdroid accounts. This might be fixed later, as I think we should merge this first before the diff get's too big.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.