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

Support for other DAV clients #41

Closed
GitHubGeek opened this issue Apr 6, 2016 · 10 comments
Closed

Support for other DAV clients #41

GitHubGeek opened this issue Apr 6, 2016 · 10 comments

Comments

@GitHubGeek
Copy link

Hi all, tried to connect 2 different clients to Davros, but no luck

  1. mount.davfs2 - Linux
  2. ExpanDrive for Windows/Mac

I suspect the issues are client-specific and has nothing to do with Davros, but want to raise them here anyway to see if anyone has already found a solution or root cause.

mount.davfs2 seems to think the https://sandstorm:<...>@api.example.com URL is invalid

ExpanDrive seems to fail with some SSL errors (it uses Python ssl lib under the hood)

@paulproteus
Copy link

Hi there,

ExpanDrive probably doesn't support SNI. See these links:

https://docs.sandstorm.io/en/latest/administering/sandcats-https/#technical-details

https://neatbytes.uservoice.com/forums/274528-solid-explorer-2-0/suggestions/8705698-please-add-sni-support-for-ssl-tls

For mount.davfs2: This URL scheme is standardized in RFC2617 as of June
1999, and I'd love to see mount.davfs2 support it. See:

It looks like this is their upstream bug tracker URL:

Can I interest you in filing bugs against those projects, to have them be
fixed accordingly? :)

Let me know what you think!

@GitHubGeek
Copy link
Author

Reported to ExpanDrive dev: Full report 😃

OTOH, the URL issue I had with mount.davfs was actually a mistake on my part. The mount command succeed but the mounted dir appeared empty. I should try to compile their latest release and test again.

@paulproteus
Copy link

Sweet, @GitHubGeek . Keep us posted. I added a comment on the issue, too.

@mnutt
Copy link
Owner

mnutt commented Apr 16, 2016

It probably isn't a blocker, but #44 should make it easier to work with other clients, too.

@dckc
Copy link

dckc commented Sep 17, 2016

I can't get a python script to work. The owncloud desktop client works fine. What am I doing wrong/differently? I tried poring over csync_owncloud.c but I'm too tired or something.

My script is:

def main(argv, stdout, environ, connect):
    username = argv[1]
    webdav = connect(
        environ['SITE_DOMAIN'], username=username,
        password=environ['SITE_PASSWORD'],
        protocol='https',
        # We serve webdav at /remote.php/webdav for Owncloud's benefit
        # -- https://github.com/mnutt/davros/issues/44
        path='/remote.php/webdav/')

    print >>stdout, webdav
    print >>stdout, webdav.ls()


if __name__ == '__main__':
    def _script():
        from sys import argv, stdout
        from os import environ

        from easywebdav import connect

        main(argv, stdout, environ, connect)
    _script()

But I lose thus:

$ python site_sync.py capsite
<easywebdav.client.Client object at 0x7f22a07c9650>
Traceback (most recent call last):
...
  File "site_sync.py", line 12, in main
    print >>stdout, webdav.ls()
  File ".../site-packages/easywebdav/client.py", line 176, in ls
    response = self._send('PROPFIND', remote_path, (207, 301), headers=headers)
  File ".../site-packages/easywebdav/client.py", line 100, in _send
    raise OperationFailed(method, path, expected_code, response.status_code)
easywebdav.client.OperationFailed: Failed to list directory ".".
  Operation     :  PROPFIND .
  Expected code :  207 UNKNOWN, 301 Moved Permanently
  Actual code   :  200 OK

I tried cadaver and curl, but the response to every request is the Davros homepage...

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Davros</title>
...
    <script src="/assets/vendor-c9cf26ccc3d8789d1b615cc8ac090d12.js"></script>
    <script src="/assets/davros-9593696a0ff51689f9ad44697484e18b.js"></script>

@mnutt
Copy link
Owner

mnutt commented Sep 17, 2016

@dckc just to confirm, are you using the URLs from the clients page? A typical curl command might look something like this:

curl -i -XPROPFIND http://sandstorm:qvs0xjGXr1_vc_5MJruxjCB7LNddui6617JYiJk2ZX_@api-76626f386bf60cc564b1697bfdffaaf8.local.sandstorm.io:6080/remote.php/webdav/

@dckc
Copy link

dckc commented Sep 17, 2016

Yes, @mnutt.

In fact, I just made a grain that I'm happy to share for testing:

$ gtest='https://webdav-debug:fEqskAi7iMI5jJ0aUZdj4Px-WmZsaqUQEttJSCPucq_@api-54d74d20f52923534a4bf37d141f7090.oasis.sandstorm.io/'

$ curl --silent -XPROPFIND "$gtest"/remote.php/webdav/ | gunzip | grep 'script src'
    <script src="/assets/vendor-c9cf26ccc3d8789d1b615cc8ac090d12.js"></script>
    <script src="/assets/davros-9593696a0ff51689f9ad44697484e18b.js"></script>

@mnutt
Copy link
Owner

mnutt commented Sep 17, 2016

It looks like there are double slashes before remote.php, resulting in the url looking like //remote.php/webdav.

$ gtest='https://webdav-debug:fEqskAi7iMI5jJ0aUZdj4Px-WmZsaqUQEttJSCPucq_@api-54d74d20f52923534a4bf37d141f7090.oasis.sandstorm.io'

$ curl --silent -XPROPFIND "$gtest"/remote.php/webdav/ | gunzip
<?xml version="1.0" encoding="utf-8"?><d:multistatus xmlns:d="DAV:" xmlns:a="http://ajax.org/2005/aml"><d:response><d:href>/remote.php/webdav/</d:href><d:propstat><d:prop><d:getlastmodified xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" b:dt="dateTime.rfc1123">Sat, 17 Sep 2016 15:31:13 +0000</d:getlastmodified><d:resourcetype><d:collection/></d:resourcetype><d:quota-used-bytes>671744</d:quota-used-bytes><d:quota-available-bytes>8416669696...

Admittedly Davros should probably do a better job of handling cases like that.

@dckc
Copy link

dckc commented Sep 17, 2016

Bingo!

Thanks, @mnutt.

ref 8845a9b/madmode-blog
aka dckc/madmode-blog@ae3d4d3

@mnutt
Copy link
Owner

mnutt commented Aug 19, 2021

I’ve since changed the URL on the clients page to the root and gotten rid of /remote.php altogether except for OwnCloud/NextCloud clients. It still wouldn’t work with double slashes, but I think that case is less likely to be hit now.

@mnutt mnutt closed this as completed Aug 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants