User auto-creation fails with 3 different clients on new/fresh davis server from v4.4.4

[n-connect]

Hello @tchapi,

Started as simple query in #56 , then extensive tests, debugging and code fixing, aaand here's a new issue. The last comment saved here finally:

Okay, multiple issues :) :

• since the bcrypt modification in PHP this spring, an error raised with app.ERROR: [500]: ValueError - Bcrypt password must not contain null character in Utils.php
• I've manually modified the connected line, using bin2hex(), however still not creating the user and bumping into another error [2024-10-13T14:16:59.998558+00:00] app.ERROR: [412]: Sabre\DAV\Exception\PreconditionFailed - An If-Match header was specified and the resource did not exist [{"file":"/usr/local/www/davis/vendor/sabre/dav/lib/DAV/Server.php","line":466,"function":"checkPreconditions","class":"Sabre\\DAV\\Server","type":"->","args":[{"Sabre\\HTTP\\Request":"PUT /dav/principals/[email protected]
• Also I'm glad I do not spent time raising a former PR for the bcrypt fix, as I've bumped into your own work in Aug 30, 2024 Fix random bytes having null terminators
• however the last release is from Aug 3, v4.4.4 -> this is what I've got almost a week ago, lucky me :)

So:

• 2 of the 3 caldav clients (macOS & IOS Calendar app) are not even get to phase in the code to auto-create a randompw'd user -> no idea why, I guess its about client side vs CalDAV RFC compatibility
• 3rd one, Thunberbird creates the account without server-side auto-creating a user but revealed both the bcrypt and the Precondition error in dev.log (Created account need to be enabled, which fails).
• fixing the v4.4.4 code manually won't make it work (even using exactly your line as below),
• checked the commits since Aug 3/v.4.4.4 to make sure I'm not missing anything connected to user auto-creation or se dependency, but no

Well, I give up. This issue is about to show that something, - blocking change(?) - has come to live since the original working user auto-creation code in 2022, which rendered it not working. Unfortunately I have no other caldav clients to test with.

Thank you for your nice work!

[tchapi]

Thanks for the issue

• I've just released v5.0.2 https://github.com/tchapi/davis/releases/tag/v5.0.2 that should fix the bcrypt problem
• I'll have a look at the auto creation, but my bandwidth is pretty terse these days, so I can't commit to anything unfortunately

As you have noticed, the auto creation code has not changed a bit since 3 years. For the auto creation code to be called, the first thing is that the imap login must succeed (and this happens in sabre/dav code, not in Davis), see this piece of code. I understand that you say that this code is not called, so are your credentials correct for the IMAP login to be successful? If you add logs in there, what does $success says? If you don't even get into the imapOpen function, then you might not even use the IMAP backend - what is your configuration like?

[n-connect]

@tchapi

Thank you for answer. I tested davis v5.0.2 by downloading the release (not using git) including the Fix random bytes having null terminators.

At first, I've have exactly the same issue, and thought there must be some other root cause:

• During installation, I had one additional step I have to do was changing the ownership of the SQLite file to the same as webserver (usually www-user in debian based distros).
• Changing the file/dir ownerships for the same user as above, applying it for the whole davis project's directories/files solved the user-autocreation issue.

---

However I'd like to ask your help with some additional details, on non-docker install:

1. Cleaning the installation directory structure: Either downloading or cloning, we have a lot of hidden files. Some connected to Git, some for the symfony. Am I right if I remove all the <.files>, except one .env file? Also what other files/directories can be removed after installation?:

• _screenshots dir,
• README.md,
• .dockerignore, + docker dir,
• phpunit.xml.dist
• tests dir
• anything else should be / can be removed after finished with the install steps in the main Readme.md? For example the bin directory, composer files, migration dirs?

2. What are the expected/suggested rights and ownerships for files & directories? Here's an example from nextcloud's admin guide:

chown -R www-data:www-data davis
find davis/ -type d -exec chmod 750 {} \; #user rwx, group r-x, others ---
find davis/ -type f -exec chmod 640 {} \; #user rw-, group r--, others ---

Edit: If I'm running last line above, I can't add new user with auto-creation in TB's Lightning Calendar and macOS Calendar app. Although IOS calendar app still can connect/auth & user-autocreate. Also existing - previously autocreated user stil can add/modify their caldav calendars through their clients. The SQLite var/data.db has read-write rights for the web user.

So quite the mixed results, making the whole code dirs/files owned by web-user (ok), set dir rights (ok), set file rights (not ok in 2 clients from the 3)

My goal is to get a finetuned/hardened install, where every function works as intended, plus disable the (very nice!!) webadmin interface (run only if needed), if user-autocreation stable. Finally, have a streamling upgrade process for a working install.

Thank you again for your code and help!

[tchapi]

Cleaning the installation directory structure:

You can have a look at the dockerignore file for a good start on what to remove. I'd not remove the bin directory (handy if you need to use the console). Removing other stuff might work or not (I don't know) but it won't give you an any more hardened install, so I would keep them.

What are the expected/suggested rights and ownerships for files & directories?

SQLite is always messy about permissions. You can look at the warning in the readme about SQLite and chown → https://github.com/tchapi/davis?tab=readme-ov-file#full-stack but that's the best of my knowledge. I wouldn't rely on it for production grade installations myself

Godspeed!

[n-connect]

@tchapi

Thank you for your answer. I was questioned of the whole project files and direcctory structure compared what I've tried - coming from the Nextcloud project.

With the SQLite file it is simple and straigtforward, if the user, which runs the PHP-FPM and webserver can write the sqlite data.db its fine. The interesting issue was and is always around the autouser creation funcions either works or not.

Right now, if the davis' own directory structure's ownership given to the web user the auto-creation works, doing the access rights code lines listed in my previous posts, some of the clients not able to set-up / and autocreation not happening. Yesterday, with the IOS Callendar application, it was possible to login and user autocreate did work:

• either just the first line of access rights for dir (740), or
• the second line for files applied. (640)

So either there is somewhere in the directory structure, which needs bigger rights or it is falls into the Caldav client compatibility level.

Do you have any knowledge, experience around these access rights with symfony PHP code structure? I recall around ~120 modules installed during composer install

Last test from my side, setting the following in nginx config right after the bundles part. One can disable access to login/dashboard/users -> in essence to webadmin UI from login page. The simple default page still loaded yet, needs some testing wihy the /index.php$ part not works. It can be added to the README.md and applied for Caddy,Apache,Lighthttpd...

    ## disable access to webadmin-ui
    location ~ /(login|dashboard|users) {
        try_files $uri =404;
    }