Unexpected behavior when issuing OPTIONS WebDAV request

[Alexander Simonov]

Unfortunately my setup was broken when I’ve updated to latest poste.io (2.3.4 FREE # 1507) yesterday. I’m using eMClient on my desktops to work with CalDAV/CardDAV. After update I’ve just noticed that eMClient start to show me a message “401 Unauthorized” and sync stopped completely at all. Nothing was helpful, even recreating account in eMClient and changing password in poste.io… I’ve been cut off from my main work instrument: calendars. And that is very bad.

I’ve started to dig in and as result I found that eMClient before doing any actual sync job is issuing “OPTIONS” request and want to get some valid standard response. But instead of getting response, poste.io sends authorization failure HTML page, even without request to perform basic auth (is this a SabreDAV part of it? Or this HTML error page looks like related to Symfony?)… As a result, eMClient is showing an error and abort any sync job (eMClient log is attached).

I’ve got this using Wireshark sniffing directly from my eMClinet to my poste.io with HTTPS disabled (sniff transcript is attached). I’ve then also reproduced it manually using curl and can confirm that “OPTIONS” behavior is invalid, while, f.e. “PROPFIND” behaviour on the same hand is valid… I also attach transcripts of curl -v for OPTIONS and PROPFIND.

So, for now, WebDAV sync with eMClient is completely broken and unusable! It is a very major issue. I’ve temporary fixed it now by manually patching code in eMClient dotnet CalDav library and changed “OPTIONS” request to “PROPFIND” one (eMClient is just checking that SabreDAV is used on server-side from OPTIONS response headers, and PROPFIND is also good for this).

Please be kind, investigate and fix it ASAP! Thanks.

[SH]

Awesome report! Thanks, will be fixed asap

[Alexander Simonov]

Thank you!

Btw, I’ve downloaded poste.io current image from my docker to local .tar and was trying to investigate where the problem resides. I’ve found a code in DavController.php execAction() that processes “OPTIONS” request for WebDav and it looks sane for me. Also Symfony routing for execAction() is looking sane for me too. But in our case the problem looks like being outside of execAction(), because it looks like issuing “OPTIONS” will never lead to call to execAction()… Because even this piece of code:

if (!$config->dav->isEnabled()) {
die('Enable DAV at your server settings');
}

is never reached also when issuing "OPTIONS" and getting error back.

It looks like some Symfony related problem or a problem with it’s configuration. I’m not expert in Symfony unfortunately, so can’t investigate it further without going deep in Symfony specifics (and this at least will be suboptimal in my case — I’m even not web/php programmer at all).

I appreciate if this info can help to fix the issue.

[SH]

fix #904 OPTIONS WebDAV request forbidden

→ <<cset a43e504e3d00>>

[Alexander Simonov]

Thank you for resolving this! When you plan to redeploy new docker image with fix? Or may be you can tell me where and what to fix manually (I can’t see changesets) and I will temporarily fix it in my deployed container by myself?

[SH]

You can remove last line from admin/config/packages/security.yaml:

        - { path: ^.*, roles: ROLE_USER }

and than you need to remove cache (admin/var/cache/prod) and killall php-fpm (it will start again automaticaly)

This line is just leftover from upgrading symfony to latest stable - DAV has its auth controlled by itself and not symfony fw

[Alexander Simonov]

Thanks!