Project

General

Profile

Actions

Feature #3187

closed

WebDAV and CORS wiki page

Added by stokito 10 days ago. Updated 10 days ago.

Status:
Invalid
Priority:
Normal
Category:
mod_webdav
Target version:
-
ASK QUESTIONS IN Forums:
Yes

Description

I spent a lot of time while configured and tested the WebDAV with CORS.
There is no any good documentation in internet so please add on a wiki a sample.
Here what worked for me:
https://gist.github.com/stokito/0a6274106d407ba6d9fb776e7773445d

The Access-Control-Allow-Origin and Access-Control-Allow-Credentials must be always added for all http methods even for a GET.

The problem is that the "Access-Control-Allow-Origin" => "*" may be not enough for POST or PUT and we must make something like

"Access-Control-Allow-Origin" => $HTTP['Origin']

I don't know ho to do that properly. Is it possible to have a dynamic header value?
For my case the `*` works fine for now so I confused if browser security settings changed.

If the $HTTP["request-method"] == "OPTIONS" then we should return a list of allowed methods.

Another problem is that a browser sends the OPTIONS preflight request without the Authorization: Basic header. So I had to put the basic auth check into condition $HTTP["request-method"] != "OPTIONS".

Ideally we just need to return a 204 code but it looks like this isn't possible with the lighttpd. Anyway, the 200 seems working fine.

I checked the configuration with these two apps:
Actions #1

Updated by gstrauss 10 days ago

  • Status changed from New to Invalid
  • Target version deleted (1.4.xx)

I spent a lot of time while configured and tested the WebDAV with CORS.
There is no any good documentation in internet so please add on a wiki a sample.

There is documentation on this site which you have either failed to read, or failed to understand.
Since you did not reference the existing documentation in your post above, I can only assume that you did not read any of it.

mod_webdav
mod_setenv

(I may add a link from mod_webdav to mod_setenv to point to the sample CORS policy there.)


You've improved some since #3055, but you are still are grossly derelict in providing references for every "must" you specify. Hint: you're wrong in many/all cases.

I don't know ho to do that properly. Is it possible to have a dynamic header value?

mod_magnet

so I confused if browser security settings changed

Access-Control-Allow-Origin

Another problem is that a browser sends the OPTIONS preflight request without the Authorization: Basic header.

Most likely issue is user-error (you) not configuring the client properly. It would be a problem with the client if the client is unable to handle authorization to access a site. If Authentication is configured, then you need access to the target resource /dav/ for OPTIONS /dav/ HTTP/1.1 to be permitted. That is how Authentication works. Authentication is working as designed.

Ideally we just need to return a 204 code but it looks like this isn't possible with the lighttpd.

mod_magnet

There are soooooooooo many false statements in your post. Your post should have been questions -- not statements -- in the lighttpd Forums given your demonstrated level of knowledge on this subject.

Actions #2

Updated by gstrauss 10 days ago

If you're wondering why you get the type of response from me that you are getting, consider that your posts sound like this:

"Since <false statement> and <false statement>, I think ..."

If you do not understand the specifications, you should not make statements. Instead, you should ask questions in the forums. Ask well-reasoned questions that demonstrate that you have read the specifications and the lighttpd official documentation. In your questions, provide references to the specifications and to lighttpd official documentation for any statements that you make, or provide factual observations of your testing. Omit your ungrounded judgements/presumptions/assumptions.

Actions #3

Updated by gstrauss 10 days ago

CORS is independent of WebDAV

If your javascript app needs CORS headers sent from the server, then configure lighttpd mod_setenv, as you have done, or use mod_magnet to do so.

Cross-Origin Resource Sharing (Mozilla Development Network)
diffuse.sh CORS requirements

Actions #4

Updated by stokito 10 days ago

Please add a sample of the CORS requests to a Wiki because the Google search doesn't helps. And additionally we need a sample of CORS requests for WebDAV that allows additional methods. My sample file works and hope it helps to people but I'm not confident in it. So that's why I asking you to fill the gap in documentation.

The problem with the OPTIONS method is that the basic auth must always allow it. Because in my case I have it configured in place but the auth may be configured somewhere else for entire www root.

The Nginx has the `return 204` and it's simple and natural. For me it looks like the Lighttpd may benefit from it too. When I googled I found a solution to create a CGI script. Likely for my case this wasn't required and the default 200 works fine.

The dynamic Allow Origin is also something that looks essential.
Using the mod_magnet makes a lot of problems. It must be installed additionally and scripts should be uploaded or created on SSH and probably `chmod +x` is needed. This increase difficulty for a regular users. I have a friend who is a regular Java Dev like me and explaining to him how to configure it's own server may make him too lazy.
The mod_magnet is great but as always with the unix way it gives a tool but not a ready to use solution.

Thank you

Actions #5

Updated by gstrauss 10 days ago

Using the mod_magnet makes a lot of problems. It must be installed additionally and scripts should be uploaded or created on SSH and probably `chmod +x` is needed.

lua is small, about < 300k on a 64-bit system, and smaller on a 32-bit system. And no, you are wrong (again): lua scripts run in lighttpd do not need +x permission. You're already asking people to edit a file for lighttpd.conf additions to configure mod_webdav, and that ought to be a new file in /etc/lighttpd/conf.d/. Yes, adding an additional file for a lua script is one additional step, but the user already has to do some basic file editing. Then again, if you provide your lua script as part of an installable package, then there is no additional step besides installing your package, and installing lighttpd-mod-magnet, which has a dependency on lua.

You have asked multiple times, and I have answered multiple times that lighttpd mod_magnet provides a way for you to return an arbitrary status code and to dynamically set response headers in lighttpd. lua is a programming language and can do many, many, many more things than the specific nginx syntax you mentioned. mod_magnet is generally the answer for "I need to do something arbitrary or dynamic" within lighttpd. (Dynamic content generation or complex, blocking behavior should be performed in a dynamic backend, be it CGI, FastCGI, SCGI, AJP13, reverse proxy, or something else)

Please add a sample of the CORS requests to a Wiki

As I said I would in my first post above, earlier today I added a short paragraph and link to mod_webdav#client-access

As I already stated: CORS policy is independent of WebDAV There is no generic one-size-fits-all CORS policy. CORS includes a set of configurable headers for a configurable policy depending on site and app requirements. If an app needs a certain CORS policy, then the app might document it, like diffuse.sh CORS requirements . The sample CORS config you provided is clearly excessive for diffuse.sh requirements. If you have a working sample config which is not throwing the kitchen sink into the headers, I may consider adding another example to mod_setenv. Allow me to repeat that CORS policy is independent of WebDAV. lighttpd mod_webdav works with numerous WebDAV clients without any CORS policy. If a random client app (e.g. in javascript) requires CORS, then you can configure lighttpd mod_setenv to accommodate, but, again note that is mod_setenv, not mod_webdav.

The problem with the OPTIONS method is that the basic auth must always allow it.

That is not my understanding of the specification. OPTIONS * may be special, but OPTIONS /target should follow the authentication policy on /target.
If OPTIONS /target did not follow the authentication policy, then that might be an information exposure security bug revealing the existence of resources to unauthenticated users.

If there are bugs in lighttpd not following the official specifications, then I will try to fix such bugs (should they exist) in lighttpd. Please point me to the official specifications if you think lighttpd is doing something incorrectly.

I will not respond further until you provide a link to the RFC specification to support your statement. I have asked too many times for you to support your (often misinformed or false) declarative statements.

Actions

Also available in: Atom