This issue seems to crop up here and there, but the owncloud client fails to sync to an owncloud instance using HTTP basic auth. The failure message unhelpfully reads "Failed to connect to ownCloud, host requires authentication".
It has been claimed that this is due to owncloud itself not supporting basic auth, but this is actually misleading, since all the interfaces, i.e. webdav, caldav, etc., do work despite basic auth, and the web interface works with basic auth credentials out of the box. Moreover, using the "ocsync" CLI tool, I can sync folders just fine, so the issue must be with the GUI client.
So is this fixable after all, or does the GUI client use any other APIs which go beyond the interfaces used by ocsync?
ownCloud itself uses basic auth, and we support it just fine. Do you mean "server-level basic auth" (i.e. configured in the web server config file) as opposed to "application level auth" (i.e. triggered from PHP)?
I am referring to server-level basic auth. Indeed the owncloud interface seems to support it just fine, as do the webdav and webcal endpoints. However, the GUI sync client does not, while manual sync using the command-line "ocsync" also works fine. Setting-up sync via the GUI yields the non-specific error messages described above. The pertinent version is 1.3.0.
I don't see how this can ever work reliably. Would you care to detail on your setup?
Maybe the problem is that for a couple of releases the GUI client did not send a proper auth header but relied on the session cookie. Now we should send the auth header again all the time (not only at login time), so it is worth to check with the upcoming beta.
My setup was on lighttpd with server-level basic auth. I think it is the documented behavior in such cases that owncloud automatically creates a user with the basic auth credentials? This has been working fine in my case.
My issue was only when using the GUI sync client. The GUI client will only work if I exlude the status.php from lighttpd's basic auth. It strikes me as curious that I would have to expose the version information like that, since the CLI sync client (ocsync) will work just fine even if status.php is protected.
So maybe this issue is resolved by now, as dragotin suggested. I can try removing the exclusion once I have the corresponding updates. Which release are the changes scheduled for?
@eigengrau No, status.php has to be publicly accessible. You may not like this, but this is how the server works. This is by design and the mobile clients are not guaranteed to work without this either.
@danimo No reason to be defensive about it. So just to make sure I correctly understand: it's a fluke that ocsync is working without access to status.php? Or are you saying that sync itself might work fine without it, but status.php is required for other applications? Since @dragotin seemed to suggest the GUI client might now also work without it. (Although it seems weird that the client would not be able to use credentials to retrieve status.php, when it can retrieve other locations just fine.)
If an exclusion for status.php is strictly required you might consider adding some remarks about server-level auth and status.php to the docs, since it doesn't seem to mention it.
@eigengrau ocsync does not check status.php. It relies on the user to provide the correct information. About what @dragotin said: It won't work. I implemented the new code, and it assumes that status.php is readable without authentication.
Thanks for clearing that up! Might want to add it to the installation docs.