Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalDAV/CardDAV service discovery (.well-known) broken for packages and subdir installs #19801

Closed
ghost opened this issue Oct 15, 2015 · 19 comments

Comments

@ghost
Copy link

ghost commented Oct 15, 2015

Steps to reproduce

  1. Install oC 8.1.3 via packages/OBS on Ubuntu 14.04
  2. Make curl request to curl -i http://127.0.0.1/.well-known/carddav
  3. See 404 reply
  4. Make curl request to curl -i http://127.0.0.1/owncloud/.well-known/carddav
  5. See 301 redirect but to the wrong location http://127.0.0.1/remote.php/carddav/

Expected behaviour

A request to curl -i http://127.0.0.1/.well-known/carddav should redirect to http://127.0.0.1/owncloud/remote.php/carddav/

Actual behaviour

CalDAV/CardDAV service discovery is broken due to the 404 on curl -i http://127.0.0.1/.well-known/carddav

There are currently three main problems here:

  1. The .well-known/caldav and .well-known/carddav URL should be at the root folder of the server according to http://sabre.io/dav/service-discovery/
  2. The OBS packages are installing oC into a subdir http://127.0.0.1/owncloud/
  3. The current rewrite rules in https://github.com/owncloud/core/blob/v8.1.3/.htaccess#L39-L45 are expecting that oC are installed at the root dir and not a subdir. This is causing wrong rewrite-rules for all of those to the root dir instead of the subdir as shown above.
@ghost
Copy link
Author

ghost commented Oct 15, 2015

cc @jnweiger

@ghost
Copy link
Author

ghost commented Oct 15, 2015

Some docs for the .well-known URLs are provided here: https://doc.owncloud.org/server/8.1/admin_manual/issues/index.html#apple-ios but i think its better to solve this directly in the package.

@jnweiger
Copy link
Contributor

Good spotting!
I can do a hackety-hack fix in the packaging code like this:

sed -i -e 's@ /\(remote\|public\)\.php@ /owncloud/\1.php@' -e 's@ \(remote\|public\)\.php@ owncloud/\1.php@'  .htaccess

@DeepDiver1975 are there more hardcoded routes like this?
I wonder why some of them have a leanding '/' and some don't ...

@ghost
Copy link
Author

ghost commented Oct 15, 2015

@jnweiger

I think you could leave the default .htaccess but add a new rewrite for the .well-known into the main owncloud.conf like:

Redirect 301 /.well-known/carddav /owncloud/remote.php/carddav
Redirect 301 /.well-known/caldav /owncloud/remote.php/caldav

as shown in https://doc.owncloud.org/server/8.1/admin_manual/issues/index.html#apple-ios

@jnweiger
Copy link
Contributor

@RealRancor hmm, wouldn't owncloud.conf settings be overwritten by the .htaccess settings then?

@ghost
Copy link
Author

ghost commented Oct 15, 2015

Mhhh, for that i don't have enough knowledge about Apache and .htaccess.

But rewriting the .htaccess won't help as this is only valid for /var/www/owncloud or http://127.0.0.1/owncloud where the .well-known rewrites needs to be in place in the main server config for /var/www/html (e.g. on Ubuntu 14.04) or http://127.0.0.1

@ghost
Copy link
Author

ghost commented Oct 15, 2015

@jnweiger Thanks

Just was testing the documented rewrites here. The two lines added there won't fix this issue.

But moving them between:

</Directory>

<Directory "@@OC_DIR@@/data/">

like:

</Directory>

    # https://github.com/owncloud/core/issues/19801
    Redirect 301 /.well-known/carddav /owncloud/remote.php/carddav
    Redirect 301 /.well-known/caldav /owncloud/remote.php/caldav

<Directory "@@OC_DIR@@/data/">

will show a correct rewrite:

curl -i http://127.0.0.1/.well-known/carddav
HTTP/1.1 301 Moved Permanently
Date: Thu, 15 Oct 2015 11:30:27 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: http://127.0.0.1/owncloud/remote.php/carddav
Content-Length: 326
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://127.0.0.1/owncloud/remote.php/carddav">here</a>.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 127.0.0.1 Port 80</address>
</body></html>

But honestly i have no idea if this will break other stuff.

@jnweiger
Copy link
Contributor

https://www.linode.com/docs/websites/apache-tips-and-tricks/redirect-urls-with-the-apache-web-server
recommeded to put the redirects inside a directory container. I'll move them outside -- thanks for testing!

@ghost
Copy link
Author

ghost commented Oct 15, 2015

The problem with the directory container is, that those rewrite would be only valid for:

http://127.0.0.1/owncloud/.well-known

where the redirect should happen an:

http://127.0.0.1/.well-known

Please be aware that i don't know if this will cause issues with other vhosts or configs as my knowledge about Apache is very basic.

@jnweiger
Copy link
Contributor

Re-Reading your initial report, I am now unsure if we really should provide http://SERVER/.well-known/
this is of course intrusive as it is outside the /owncloud namespace.

Is'nt it sufficient to provide http://SERVER/owncloud/.well-known instead?
Or both?

@ghost
Copy link
Author

ghost commented Oct 15, 2015

Thats a really good question. Just found out that i have misread the http://sabre.io/dav/service-discovery/ linked above about the location of the .well-known

Within the https://tools.ietf.org/html/rfc5785 there are only .well-known URLs defined at the root dir and the FAQ is describing why no .well-known URLs for subdirs are defined https://tools.ietf.org/html/rfc5785#appendix-B

So currently i don't have an idea whats the best approach.

@RobinMcCorkell
Copy link
Member

The packages cannot make any reasonable attempt at the well known redirects, since there could already be stuff there. We should just put a note in the documentation that the user needs to set that up manually, if they want it.

@jnweiger
Copy link
Contributor

Thanks @Xenopathic that means, we try to fix something with packaging logic, that also does not work when installing from the archives. Then it is a wontfix on my side. Sorry.

@RobinMcCorkell
Copy link
Member

@jnweiger Agreed, this isn't the responsibility of the packages, since it affects the whole server.

@ghost
Copy link
Author

ghost commented Oct 15, 2015

Absolutely fine with that so closing that for now.

Maybe just https://doc.owncloud.org/server/8.1/admin_manual/issues/index.html#apple-ios needs to be put somewhere prominently within the Apache documentation instead of the issues?

@ghost ghost closed this as completed Oct 15, 2015
@jnweiger
Copy link
Contributor

I've left behind a comment in owncloud.conf refering to the documentation.

@ghost
Copy link
Author

ghost commented Oct 15, 2015

Thanks, that works for me. Ref for the doc part: owncloud-archive/documentation#1800

@strk
Copy link

strk commented Apr 24, 2016

The owncloud.conf as of 9.0.1 doesn't contain the reference to the documentation anymore, and webdav still doesn't work out of the box

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants