mod_authz_svn blocks POST if any sub-path is readonly

[solsson]

For example with RWEB=fpm we can't use the e.mkdir service on any path that has a read-only descendant. See Reposoft/rweb@7f8a12d

My initial reaction is that this is a bug with mod_authz_svn, as they handle GET but not POST. True, POST may affect a subtree. However it'd have to be converted, server side like rweb does, to a Subversion operation first.

@takesson Do you have ideas? The only thing I can come up with now is to separate external and internal hosts (again) and load the mod_authz_svn module only on the internal host.

[takesson]

Since POST can affect a subtree and rweb is kind of intruding on the svn URL, I think mod_authz_svn does more or less the right thing.

Alternatives:

• Have rewrite do (R)edirect instead of (P)roxy. The forms will be on different urls and I presume post to the /repos-web URL.
• Make the form consistently POST to the /repos-web/... URL regardless of R / P in rewrite.

We might have customers (not many) with integrations that POST towards the /svn/... URL in order to upload files. Not sure how such a client (curl, mostly) would handle a Redirect during POST.

[solsson]

Redirect for POST during file upload is quite bad as you'll send the entire file again. That's why we try to validate write access when displaying the form, due to how BASIC auth works.

Make the form consistently POST to the /repos-web/... URL regardless of R / P in rewrite.

Sounds good. I once thought we'd be phasing out those URLs but it's quite impractical due to static resources there etc.

[takesson]

Changing rewrite to Redirect would redirect Browser users before form display. Changing rweb to POST to /repos-web would just slightly improve visuals by staying on the /svn url. POST redirect is only a problem for integrations and they would need to be changed anyway. It seems... right? /Thomas Å.

…

On 11 Dec 2017, at 18:26, solsson ***@***.***> wrote: Redirect for POST during file upload is quite bad as you'll send the entire file again. That's why we try to validate write access when displaying the form, due to how BASIC auth works. Make the form consistently POST to the /repos-web/... URL regardless of R / P in rewrite. Sounds good. I once thought we'd be phasing out those URLs but it's quite impractical due to static resources there etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[solsson]

Maybe redirect is required due to how BASIC auth works. I've had issues in the past with browsers not sending credentials to a sibling path.

[takesson]

I will switch to Redirect for e.* services on some dev servers and evaluate for some weeks. Need to investigate API consumers. /Thomas Å.

…

On 11 Dec 2017, at 18:54, solsson ***@***.***> wrote: Maybe redirect is required due to how BASIC auth works. I've had issues in the past with browsers not sending credentials to a sibling path. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[takesson]

Maybe redirect is required due to how BASIC auth works. I've had issues in the past with browsers not sending credentials to a sibling path.

Yes, I am seeing the BASIC auth sibling path issue. Might actually be worse if doing POST to different path.

Perhaps we should require auth on / instead to avoid sibling issue. Now, we are doing redirect on / which happens before authn. Options:

• Get mod_rewrite to do authn before redirect, some forward-looking subrequest perhaps.
• Change the redirect to a page, potentially doing the redirect with HTML instead?