Cannot connect due to CORS error about obsidian-livesync HOT 9 OPEN

@thany I had similar issue and found out it was because of the attachment files.
You should check the configuration with nginx to allow the sync for bigger file size.

Try to put this in nginx conf and restart the service:
client_max_body_size 100M;

from obsidian-livesync.

Hi. I am not familiar with the LiveSync plugin, but I have a question.
Is the LiveSync plugin version up-to-date?

Debug info
1: Self-hosted LiveSync v0.19.23

The current LiveSync plugin latest is v0.21.5. (Releases · vrtmrz/obsidian-livesync)

I apologize if this is not relevant.

from obsidian-livesync.

It is up-to-date now 😀

But it didn't help to resolve the issue, unfortunately.

from obsidian-livesync.

I have couchdb running in a docker container, and cannot find a nginx config anywhere. Can you point out where I'm supposed to add that config line exactly?

At the filesystem root, find | grep nginx yields 0 results.

Btw, couchdb is an Apache project, so why would they use nginx for the webserver part? 😀

Oh and also, if filesize is the problem, then should it not be able to connect to couchdb in the first place? Because before that happens, it has no chance of even trying to send any file.

from obsidian-livesync.

I use Nginx for the reverse proxy to access livesync server via a domain name.
Maybe this is a difference issue of mine.

from obsidian-livesync.

And sure I can enable CORS in couchdb itself, but then two more questions would arise:

1. What domain should I fill in to allow? Because I'm obviously not going to allow everything. Couchdb admin says to has to start with http/https, but Obsidian is not a website.
2. Obsidian is a desktop application, so why would it need CORS in the first place? cmiiw, but CORS is meant communication from javascript on a website to another domain. But in this case, there's no domain to be had...

from obsidian-livesync.

I am really sorry, and, thank you all for your patience and cooperation!

And sure I can enable CORS in couchdb itself, but then two more questions would arise:

We should enable CORS in CouchDB and leave handlings to it. CouchDB will pick a suitable origin for each request from configured values. Each platform uses a different origin.

1. app://obsidian.md, capacitor://localhost and http://localhost should be set. This can be configurable by the Check button; from the Check database configuration of the setting dialogue in Self-hosted LiveSync on Obsidian. (I think that this button could be Doctor as in some traditions).
   Note: it could not be configurable from the Web UI. We have to configure it by using REST API or editing INI files.
2. I have been so surprised as same on you. Obsidian is built on the web technology. The desktop version uses app://obsidian.md for the origin. (app is not the actual protocol scheme, but a real one.) This can be revealed by evaluating window.location.origin in DevTools. As noted above, this varies from platform to platform.

from obsidian-livesync.

1. This can be configurable by the Check button; from the Check database configuration of the setting dialogue in Self-hosted LiveSync on Obsidian.

Except the problem is that it too, will throw the same CORS error. But it can be added forcibly on the "Main config" page in the couchdb admin config. Not sure if that's a "healthy" thing to do, because the requirement for http/https is probably there for a reason.

Either way, I don't believe Obsidian should behave like it's a faux website. I'm not sure where this should be fixed if possible. Is it a bug in Obisidan, or maybe in Electron?

from obsidian-livesync.

Thank you for your good point! I have looked into it again, to find what should it be to the origin.
Then, I collected some information. Let me share it.

CouchDB can accept origins which have non-HTTP schemes neither via HTTP API nor the ini file. A CORS origin could have them, this would be based on old-fashioned CORS specification (RFC-6454 and RFC-3986).
RFC-3986 seems to be refined as URL Living Standard, these are defined as special-scheme in it.
Therefore, this could be the problem of Fauxton; which is the web-frontend of CouchDB. However, it is web-frontend and may be designed that way as far as I looking at issues on their repo.

On the other hand, iOS and Electron use non special-scheme.
iOS (Based on Capacitor) seems to use capacitor://localhost as this. I could not find the exact source of the information, but Electron uses app:// in their sample

This might mean that it seems to be well-designed in each their area; even though if they makes very complicated situation for us.

I hope that my information will help us!

from obsidian-livesync.