CalDAV, CardDAV support as a client and server

šŸ’” Suggestion Box
42

NextCloud uses the sabre/dav package.

This package should work well for Suite to sync contacts and calendars to and from NextCloud, to and from user devices and computers, as client and server, with sync in both directions.

43

My package uses SabreDAV as well.

1 Like
44

I have a fully functioning CALDAV server for SuiteCRM - bidirectional (Sabre based).
I adapted it from a long time defunct piece of software that did the same.

Not sure about the legal implications making this public - e.g. open source.

@pgr is it possible to have chat about this in another channel?

2 Likes
45

o.k. - I would be interested in this software. Looking for a way to access the contacts in SuiteCRM.

46

@jobst I donā€™t use the features and any way I wouldnā€™t be the correct person for you to talk to.

I suggest sending a private message here on the forums to someone from SalesAgility.

47

Tried getting CardDAV up and running again,ā€¦ my nemesisā€¦
Stack: Ubuntu 22.04, ISPConfig, PHP 8.2, SuiteCRM 8.6.2.
Learnings so far;
A. Do not run ā€œcomposer update --no-devā€ in your SuiteCRM folder, I messed up my server that way! Instead run ā€œcomposer install --no-devā€ in your legacy folder.
B. Set the BaseUri line to: $baseUri = ā€˜/legacy/custom/DAVServer/davserver.phpā€™;
C. Load the SabreDAV autoload file prior to loading the custimized SugarDAV files. Thus, the line [require_once ā€˜SabreDAV/vendor/autoload.phpā€™;] must be placed above/prior to the line [require_once ā€˜custom/DAVServer/SugarCalDAVBackend.phpā€™;]
if my understanding is correct, the SabreDAV autoload file will load the default functions and the SugarDAV scripts will modify those.
D: Check the service at http(s)://[server]/legacy/custom/DAVServer/davserver.php My output looks responsive.

My current errors:

  1. Trying URL http(s)://[server]/legacy/custom/DAVServer/davserver.php/principals/johndoe
    Result: white page with ā€œAccess denied.ā€ message.
  2. Trying URL http(s)://[server]/legacy/custom/DAVServer/davserver.php/addressbooks/johndoe/Contacts
    Result: white page with ā€œAccess denied.ā€ message, logging: [Wed Sep 04 02:37:41.781039 2024] [proxy_fcgi:error] [pid 709697] [client 1.2.3.4:61293] AH01071: Got error ā€˜Access to the script ā€˜redirect:/index.php/johndoe/Contactsā€™ has been denied (see security.limit_extensions)ā€™
    This looks like SuiteCRM 8 redirecting the Sabre traffic on file davserver.php to the defaut index.php file. Maybe the .htaccess file.

Does anybody know to proceed on this?

48

Ensure that the davserver.php file and its parent directories have the correct permissions and ownership.

sudo chown -R www-data:www-data /path/to/suitecrm/legacy/custom/DAVServer
sudo chmod -R 755 /path/to/suitecrm/legacy/custom/DAVServer

Try to modify .htaccess like below:

<Files "davserver.php">
    Require all granted
</Files>

Check php.ini file. You can temporarily set security.limit_extensions to an empty value to test.

security.limit_extensions = ""

Remember to restart your apache2 server:

sudo systemctl restart apache2
49

Hi rsp, thank you for pitching in!
The permissions, ownership and server restart are already part of my reset script. For good measure Iā€™ve added your lines to it. The .htaccess lines I added to both the .htaccess file in /public and in /public/legacy.
The security.limit_extensions is new to me and has been added to php.ini. Thanks!
Ran the reset script again and logged davserver.php in to my SuiteCRM account (that works!).
However, the issues remain. Even when using PHP 7.4.
Interesting is that in the html output of davserver.php, thereā€™s a link ā€œGo to parent [ Plugins]ā€. Clicking that provides the following error:
Requested uri (/legacy/custom/DAVServer/davserver.php?sabreAction=plugins) is out of base uri (/legacy/custom/DAVServer/davserver.php/)
Iā€™ve tried adding a trailing / to the $baseUri, but it doesnā€™t change the errors.
Thus http(s)://[server]/legacy/custom/DAVServer/davserver.php/addressbooks/johndoe/Contacts results in ā€˜Access to the script ā€˜redirect:/index.php/johndoe/Contactsā€™ has been denied (see security.limit_extensions)ā€™

50

Update davserver.php Configuration: Verify if the $baseUri is correctly set in your davserver.php file. It should be set to the path relative to your web root.

$baseUri = '/legacy/custom/DAVServer/davserver.php/';

You may need to adjust this setting to allow .php files or add specific paths if they are restricted.

security.limit_extensions = .php

51

Verified that the $baseUri is good, else the html interface will fail. With or without the trailing / doesnā€™t seem to make a difference in the error messages.

The default of security.limit_extensions is .php .phar that should be good.
Googling I found suggestions to set it to FALSE or .php /
The error messages remain the same. For now Iā€™ve settled on .php /

Gunnicom mentions that his scipt was tested on Linux PHP 8.2.11 - Mysql 8.0.34 - SuiteCRM 7.14.0.
I do remember it briefly working om SuitCRM 7, only to be lost again on the upgrade to 8.2.
Iā€™m thinking I should setup a test server, confirm that itā€™s working, upgrade and see at what point it fails.

52

Do you have any firewall on your server?

53

Yes, of course, even though the server is internal.

54

@Ozzie76 I never tried this on Suite 8.x.
composer update was neccessary because with composer install the merge plugin did not merge the composer file from the ext/ folder. So you may need to edit your composer file. But I am not sure about that.
Other than that I can not help because I am not running 8.x and may never switch to that.
It still does work for me on PHP 8.2 SuiteCRM 7.14.x

55

Aha, so composer update is needed,ā€¦ wow, thanks for clarifying that! With pgrā€™s input elsewhere in the forum I was sure that was one of the issues. Wondering if that was one of the issues why there was an error on the Sabre/Dav functions. Thatā€™s why I moved the autoload file up.

Yes, SuiteCRM 7 is working, great to hear that it still is. Extra motivation to setup a test server. SuiteCRM 8 has a redirect between itā€™s ā€œcoreā€ and ā€œlegacyā€ parts. That could be the cause.

Iā€™ve also tried setting up a separate vhost on the same server and using that to access the database directly. Do you think that approach would work, or would it run into dependency issues for not being in the same directory tree?

56

You may try to just add the davserver as entrypoint. That would be the more Suite/Sugar-way anyway. Maybe that helps with the routing in Suite8.

57
1 Like
58

Thanks for pointing to the Entry Points. Iā€™m looking into that.

The SCRM 8 rewrite issue mentioned earlier is most likely coming out of the /public/.htaccess file. There are a couple files rerouting to index.php for security and missing files. Tried adding an exception for davserver.php as rsp had mentioned, but canā€™t get it to work.

Tried the separate vhost approach, but went down the rabbit hole on that. Needed to change files in the orginal SuiteCRM vhost too, which wasnā€™t an option.

Have now built a new server to test 7.14.5 and 8+.
Template: https://www.howtoforge.com/how-to-install-suitecrm-on-ubuntu-22-04/
However, the template is using nginx and it took me a while to figure out that composer needed to be run as nginx user.
On ā€œsudo -u nginx composer update --no-devā€ Iā€™m getting a bunch of similar errors: E.G.
Class SugarAutoLoader located in ./include/utils/autoloader.php does not comply with psr-4 autoloading standard (rule: SuiteCRM\ => ./include). Skipping.
Skipping doesnā€™t sound good. Good thing is that the davserver.php is doing something on the web interface, but the carddav plugin isnā€™t responding yet.

59

YAY!, success on the 7.14.5 test server.
Took sabre/Davs mysql examples and expanded that with Gunnicomā€™s Sugar scipts on a separate vhost.
https://sabre.io/dav/caldav/ and worked with the MySQL and groupwareserver.
A. There are pretty good server config examples for Apache2 and NGINX at the baikal part or sabre.io.
http://sabre.io/baikal/install/
Based on that example I changed
fastcgi_split_path_info ^(.+.php)(/.+)$; to
fastcgi_split_path_info ^(.+.php)(.*)$;
itā€™s just a /, but apparently an important one.
Havenā€™t been able to convert this knowledge into something useful for Apache2 (yet), but at least thereā€™s a success on nginx.
B. Changed 2 davservers.php variables to align them with the sabre.io dav sql examples.
$addressBookBackend to $carddavBackend
$calendarBackend to $caldavBackend
B. Gunnicoms examples use a logging module: $GLOBALS[ā€˜logā€™]->error($e->getMessage());
This logging module isnā€™t part of a virgin system. After it got taken out, the davserver started spinning.

Will add SCRM 8.6 to the system and try to hook up the dav vhost to it. Fingers crossed :slight_smile:
Thanks you rsp and gunnicom!!