Resolve the OpenPaaS ids with DAV

[chibenwa]

Description of the bug

This way TMail will not depend on OpenPaaS and would be more compatible with DAV clients.

OUTCOME: Remove the OpenPaaS client & related code

How

curl -k -u '[email protected]:xxxxxxxxxxxxxxxxx' https://dav.linagora.com -X PROPFIND -d '<?xml version="1.0" encoding="UTF-8" ?><D:propfind xmlns:D="DAV:"><D:prop><D:displayname/><D:principal-collection-set/><D:current-user-principal/></D:prop></D:propfind>' | xmllint --format - 

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav">
  <d:response>
    <d:href>/</d:href>
    <d:propstat>
      <d:prop>
        <d:principal-collection-set>
          <d:href>/principals/users/</d:href>
          <d:href>/principals/resources/</d:href>
          <d:href>/principals/domains/</d:href>
        </d:principal-collection-set>
        <d:current-user-principal>
          <d:href>/principals/users/5f50a663bdaffe002629099c/</d:href>
        </d:current-user-principal>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:displayname/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/principals/</d:href>
    <d:propstat>
      <d:prop>
        <d:principal-collection-set>
          <d:href>/principals/users/</d:href>
          <d:href>/principals/resources/</d:href>
          <d:href>/principals/domains/</d:href>
        </d:principal-collection-set>
        <d:current-user-principal>
          <d:href>/principals/users/5f50a663bdaffe002629099c/</d:href>
        </d:current-user-principal>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:displayname/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/calendars/</d:href>
    <d:propstat>
      <d:prop>
        <d:principal-collection-set>
          <d:href>/principals/users/</d:href>
          <d:href>/principals/resources/</d:href>
          <d:href>/principals/domains/</d:href>
        </d:principal-collection-set>
        <d:current-user-principal>
          <d:href>/principals/users/5f50a663bdaffe002629099c/</d:href>
        </d:current-user-principal>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:displayname/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/addressbooks/</d:href>
    <d:propstat>
      <d:prop>
        <d:principal-collection-set>
          <d:href>/principals/users/</d:href>
          <d:href>/principals/resources/</d:href>
          <d:href>/principals/domains/</d:href>
        </d:principal-collection-set>
        <d:current-user-principal>
          <d:href>/principals/users/5f50a663bdaffe002629099c/</d:href>
        </d:current-user-principal>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:displayname/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

[vttranlina]

I understand that we are trying to be compatible with all DAV servers, not just the customized openpaas DAV server from Linagora.

The value '[email protected]:xxxxxxxxxxxxxxxxx' (user/pass) is the credentials of each user or the admin?
If it is to each DAV user, where does this value come from?

If it is the admin’s credentials, the syntax you used doesn’t seem quite right (I don’t see the queried user’s username in either the request or the response).

[chibenwa]

The value '[email protected]:xxxxxxxxxxxxxxxxx' (user/pass) is the credentials of each user or the admin?
If it is to each DAV user, where does this value come from?

Impersonation yields the exact same results as direct user authentication. So it works.

If it is the admin’s credentials, the syntax you used doesn’t seem quite right (I don’t see the queried user’s username in either the request or the response).

We already have impersonation in the code base. I bet somebody familiar with the topic will be able to understand that.

[vttranlina]

I know the impersonation logic (I implemented it in tmail)

The correct should be: btellier&[email protected]:xxxxxxxxxxxxxxxxx

anw, I understand