Nextcloud & CORS

[mehrdad-shokri]

I have setup a development environment and it's running on http://localhost:1337/.
Nextcloud server is running on 192.168.10.10. So when I try to access 192.168.10.10/remote.php/webdav from webdav-fs I get a CORS error:

Failed to load http://192.168.10.10/server/remote.php/webdav/: Response to preflight request doesn't 
pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:1337' is therefore not allowed access. The response had HTTP status code 401.

What's the appropriate way to solve CORS problem for Nextcloud.
I know this may not be related to this project but I thought you may know the answer.

[mehrdad-shokri]

Now that I've installed this cors extension for Chrome, I get another error:

OPTIONS http://192.168.10.10/server/remote.php/webdav/ 401 (Unauthorized)

Failed to load http://192.168.10.10/server/remote.php/webdav/: Response for preflight has invalid 
HTTP status code 401

my Code is pretty simple:

const wfs = require("webdav-fs")(
  "http://192.168.10.10/server/remote.php/webdav",
  "admin",
  "admin"
);
wfs.readdir("/", function(err, contents) {
  if (!err) {
    console.log("Dir contents:", contents);
  } else {
      console.log("Error:", err.message);
  }
});

[perry-mitchell]

Yeah CORS is a real pain. I’m not sure what might be possible with Nextcloud in this area. This library works with ownCloud but not with Nextcloud, so it’s quite evident that they changed the WebDAV side of things.

The reason this library works with Nextcloud in our Buttercup applications is because most of them are not web based.. so they don’t require CORS.

That error you’re seeing might be your plugin breaking the request: we send an Authorization header with each request, which again works on NodeJS for instance, so something went missing with your request.

I would recommend continuing this discussion on the parent WebDAV library: webdav-client - As the core to webdav-fs’ functionality comes from there.

I’m not currently at a machine so I’ll link this issue then. I would recommend trying with that library first..

[mehrdad-shokri]

I tested the request being sent with both this and webdav-client lib.
Both of them have identical header like the attached photo. I also tested it with the extension being enabled and disabled.

I've pushed the code to here take a look if you want.
it's pretty simple, requires webdav and sends a request to a remote webdav server.

[perry-mitchell]

Hmm.. Strange. The Authorization header should be there. The 401 probably means that it's not getting there.

When using these with Buttercup, we're commonly overriding the built in fetch method, which is commonly node-fetch as NodeJS is the base environment. When using it in browsers, we should override the fetch method using this helper. Might be best to use the native fetch, but I expect that we'll still encounter CORS errors.

[mehrdad-shokri]

Hmm.. Strange. The Authorization header should be there. The 401 probably means that it's not getting there.

Yep, it doesn't get submitted. obvious from the screenshot included.

Any suggestions to fix this? Is this a bug or my misconfiguration?

[perry-mitchell]

I don't think it's a bug. I'm using both libraries at their current versions on several applications that require auth. I would suggest debugging the library by either putting breakpoints in before it sends the request or console.log'ing the headers before it sends. If you see Authorization then, the issue will be somewhere else.

If you want to confirm that this works, and see what a successful payload looks like, you might try another webdav service. Yandex provides free webdav accounts which work fine with these libraries.

[perry-mitchell]

On the note of Nextcloud support - I feel that the issue lies with their implementation. This issue has been going on for some time (EDIT: Just saw that you had come from this issue..).

I would like to get back to testing with Nextcloud but I don't have time currently. If you do find something that works, I'd really love it if you shared it here - it would benefit a good amount of users that are after the same thing you are.

[mehrdad-shokri]

I would like to get back to testing with Nextcloud but I don't have time currently. If you do find something that works, I'd really love it if you shared it here - it would benefit a good amount of users that are after the same thing you are.

Sure I would.

This lib weights over 500k which I see pretty high for a client side library.
I'm in doubt whether I should use it in client side or divide the purpose into 2 different projects.
What I mean by that is that the frontend client sends ajax request to some backend and that backend tries to communicate with the WebDAV and then returns response.
What's your opinion for that? Do you think there are advantages of communicating with WebDAV in client side that I haven't thought about?
Also note that I believe communicating with webDAV in backend is more secure since we aren't composing password to the client. Don't you think that way?

[Ricks-ha]

This issue is now open for nearly 18 months did anything happen to solve this yet?

[perry-mitchell]

@Ricks-ha Well it’s not the responsibility of this library nor myself to solve CORS issues with Nextcloud, and I don’t actually have the bandwidth to look into it. Unfortunately this issue stands a good chance of being closed so without someone looking at it that runs a Nextcloud server themselves I’m afraid that it’d be better to try and solve it yourself by digging into the code.

I’m quite confident the issue is with Nextcloud and not this library.

[perry-mitchell]

What's your opinion for that? Do you think there are advantages of communicating with WebDAV in client side that I haven't thought about?

If you're not using the full range of WebDAV features, then I'd definitely think hosting this lib server-side and exposing some basic API would be the right way to go.

Also note that I believe communicating with webDAV in backend is more secure since we aren't composing password to the client. Don't you think that way?

Depending on the service you're reading from this definitely sounds more secure.

[perry-mitchell]

I'm going to close this issue as currently it does not look like it concerns any of this library's features. Please see the new CORS notice in the readme.