Webinterface shows all principals

[HLeithner]

Hi,

since 2.1 the web interface shows me all principals and I'm not sure why.
My sabredav is set up with hideNodesFromListings (But maybe this has nothing todo with it).

The principals shows 2 nodes calendar-proxy-read and write, is it possible that I need a acl pluging that only shows the allowed principals?

thx

[evert]

Between version 2.0 and 2.1 we made all principals discoverable by default. This was pretty much required to allow scheduling to work.

There's a sort of 'trick' you can use to completely block users from getting the full list of users. You do this by setting the $disableListing property to true in your principal collection. This is likely Sabre\CalDAV\Principal\Collection or Sabre\DAVACL\PrincipalCollection, but while it disables discoverability, it does not prevent people from finding out principals exists by doing a GET or PROPFIND request on a full principal url.

[HLeithner]

It's not so bad if I could find them. But Listing is a bit a problem in a shared environment.
Whats the drawback if I disableListing for calendar apps?
And is there a possibility to control the visibility per item with the acl plugin?

If I have multiple "Groups" (Like different companies) that should only see there group members, is this possible in any way?

[evert]

Hi!

Sorry for not responding sooner, I missed your reply and then all the holidays happened.

The drawback of $disableListing is that you can't easily browse through all existing principals with the browser plugin. You also can no longer perform PROPFIND to discover everything that's there.

It would be possible to control visibility per item, but you need to subclass the Sabre\DAVACL\Principal class and return appropriate rules from the getACL() method as you see fit.

Hope this helps. Closing this ticket for now, but feel free to continue commenting.

[HLeithner]

Hi,

ok I will try this but have some problems adding my own Principal class to sabre dav.
Could you give me a hint how this works?
atm I have my own AuthBackend that adds new user to the table on request that was an easy task, but I think I stuck with adding a replacement Principal ACL class to sabreDav

thx
Harald

[evert]

The way that would work right now is that you'd need to subclass Sabre\DAVACL\PrincipalCollection

That class creates an instance of Sabre\DAVACL\Principal for every user/principal.

[HLeithner]

OK and howbdo I attach this class?

[evert]

Your server.php should already instantiate it. Either Sabre\DAVACL\PrincipalCollection or Sabre\CalDAV\Principals\Collection. they are mostly the same.

[HLeithner]

So,

I found a way how it works but I think thats not a nice way looks more like a workaround manly because I have some problems the concept.

function getACL() {
        global $server;
        $auth = $server->getPlugin('auth');
        $user = $auth->getCurrentUser();
        list(, $domain) = explode('@', $user);
        list(, $nodeDomain) = explode('@', $this->principalProperties['{http://sabredav.org/ns}email-address']);

        if ($domain != $nodeDomain) {
            $acl = [];
        } else {
            $acl = parent::getACL();
        }
        return $acl;
}

I check if the user has the same domain as the node, is there a cleaner way to the get current User?

[evert]

Normally it's not considered the 'correct way' to check for the current user. Instead, you just want to specify an ACL rule for the users you want to give access, and let the ACL plugin determine what that is.

So in an ideal world you create separate principals per-domain. These would become your 'group principals'. Then you can add users to the member list of those domains. Then lastly, you return an ACL rule that allows the domain to get access to the properties for that principal.

However, that might be a bit harder. If you do want to use the 'current user', I think you should consider injecting the auth plugin or server object into the constructor of your principal collection and the principal class, so you can avoid the global.

This is a decent hack though. It's self-contained in one function, it's just that globals are usually frowned on.

[HLeithner]

So more or less the same way how calender delegation works, that makes more sense.

thx