You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Marc Speck <ma...@gmail.com> on 2008/11/13 11:21:51 UTC

Secured reverse proxy for WebDav

I want to reverse proxy webdav access with Apache 2.2. Besides routing and
other stuff, the web server also encrypts the connections. While this works
fine with ProxyPass and ProxyPreserveHost for the host name, it fails for
sending the decrypted request from Apache to Jackrabbit. The reason is that
Jackrabbit cannot know that it is supposed to deliver encrypted links in his
responses.

I think the problem/solution lies in the constructor of WebdavRequestImpl.
Instead of creating hrefPrefix in the constructor of WebdavRequestImpl,
could it be passed by the AbstractWebdavServlet.service() method? The
following change enables implementations of AbstractWebdavServlet to parse
their particular hrefPrefixes:

Index: AbstractWebdavServlet.java
===================================================================
--- AbstractWebdavServlet.java    (revision 713696)
+++ AbstractWebdavServlet.java    (working copy)
@@ -176,7 +176,7 @@
     protected void service(HttpServletRequest request, HttpServletResponse
response)
             throws ServletException, IOException {

-        WebdavRequest webdavRequest = new WebdavRequestImpl(request,
getLocatorFactory());
+        WebdavRequest webdavRequest = new WebdavRequestImpl(request,
getLocatorFactory(), getHrefPrefix(request));
         // DeltaV requires 'Cache-Control' header for all methods except
'VERSION-CONTROL' and 'REPORT'.
         int methodCode = DavMethods.getMethodCode(request.getMethod());
         boolean noCache = DavMethods.isDeltaVMethod(webdavRequest) &&
!(DavMethods.DAV_VERSION_CONTROL == methodCode || DavMethods.DAV_REPORT ==
methodCode);
@@ -209,6 +209,12 @@
         }
     }

+    protected String getHrefPrefix(HttpServletRequest request) {
+        String host = request.getHeader("Host");
+        String scheme = request.getScheme();
+        return scheme + "://" + host + request.getContextPath();
+    }
+
     /**
      * Executes the respective method in the given webdav context
      *



Sure enough, I'm also happy to learn about existing/better solutions...
Marc

Re: Secured reverse proxy for WebDav

Posted by Marc Speck <ma...@gmail.com>.
On Fri, Nov 21, 2008 at 9:22 AM, Julian Reschke <ju...@gmx.de>wrote:

> Marc Speck wrote:
>
>> Oh, ok. So you are saying that the following should work?
>>
> >
>
>> Index:
>>
>> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
>> ===================================================================
>> ---
>>
>> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
>> (revision 712647)
>> +++
>>
>> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
>> (working copy)
>> @@ -108,9 +108,7 @@
>>         this.factory = factory;
>>         this.ifHeader = new IfHeader(httpRequest);
>>
>> -        String host = getHeader("Host");
>> -        String scheme = getScheme();
>> -        hrefPrefix = scheme + "://" + host + getContextPath();
>> +        hrefPrefix = getContextPath();
>>     }
>>
>>     /**
>>
>
> Depends on where exactly hrefPrefix is used, of course. So in theory: yes.


 Sure. I opened an issue https://issues.apache.org/jira/browse/JCR-1873 but
I do not know the implementation well enough to suggest a patch. There are
obviously more changes necessary than the one above.


>
>
>  Though why is there the scheme and host in there? I'm somewhat puzzled...
>>
>
> Because somebody just looked at examples, and didn't read the spec
> carefully (as it frequently happens).
>
> Several WebDAV implementations already do return just the path (IMHO Apache
> moddav for instance), so clients have had to accept that for a long time.
>

Ok, thanks for the insights.
Marc

Re: Secured reverse proxy for WebDav

Posted by Julian Reschke <ju...@gmx.de>.
Marc Speck wrote:
> Oh, ok. So you are saying that the following should work?
 >
> Index:
> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
> ===================================================================
> ---
> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
> (revision 712647)
> +++
> jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
> (working copy)
> @@ -108,9 +108,7 @@
>          this.factory = factory;
>          this.ifHeader = new IfHeader(httpRequest);
> 
> -        String host = getHeader("Host");
> -        String scheme = getScheme();
> -        hrefPrefix = scheme + "://" + host + getContextPath();
> +        hrefPrefix = getContextPath();
>      }
> 
>      /**

Depends on where exactly hrefPrefix is used, of course. So in theory: yes.

> Though why is there the scheme and host in there? I'm somewhat puzzled...

Because somebody just looked at examples, and didn't read the spec 
carefully (as it frequently happens).

Several WebDAV implementations already do return just the path (IMHO 
Apache moddav for instance), so clients have had to accept that for a 
long time.

BR, Julian

Re: Secured reverse proxy for WebDav

Posted by Marc Speck <ma...@gmail.com>.
Oh, ok. So you are saying that the following should work?

Index:
jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
===================================================================
---
jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
(revision 712647)
+++
jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
(working copy)
@@ -108,9 +108,7 @@
         this.factory = factory;
         this.ifHeader = new IfHeader(httpRequest);

-        String host = getHeader("Host");
-        String scheme = getScheme();
-        hrefPrefix = scheme + "://" + host + getContextPath();
+        hrefPrefix = getContextPath();
     }

     /**


Though why is there the scheme and host in there? I'm somewhat puzzled...
Marc




On Mon, Nov 17, 2008 at 6:44 PM, Julian Reschke <ju...@gmx.de>wrote:

> Marc Speck wrote:
>
>> Julian, thanks for your answers. I might have written my answer in an
>> unclear way but I interpret "Absolute paths are fine." as absolute URLs
>> like
>> http://myvirtualhost.example.org/dav/wsp/mynode should be used in the
>> content of a response. This means that the scheme and the host need to be
>>
>
> No, that's an absolute URI. That works of course, but the absolute *path*
>
>  /dav/wsp/mynode
>
> is fine as well.
>
>  ...
>>
>
> BR, Julian
>
>

Re: Secured reverse proxy for WebDav

Posted by Julian Reschke <ju...@gmx.de>.
Marc Speck wrote:
> Julian, thanks for your answers. I might have written my answer in an
> unclear way but I interpret "Absolute paths are fine." as absolute URLs like
> http://myvirtualhost.example.org/dav/wsp/mynode should be used in the
> content of a response. This means that the scheme and the host need to be

No, that's an absolute URI. That works of course, but the absolute *path*

   /dav/wsp/mynode

is fine as well.

> ...

BR, Julian


Re: Secured reverse proxy for WebDav

Posted by Marc Speck <ma...@gmail.com>.
Julian, thanks for your answers. I might have written my answer in an
unclear way but I interpret "Absolute paths are fine." as absolute URLs like
http://myvirtualhost.example.org/dav/wsp/mynode should be used in the
content of a response. This means that the scheme and the host need to be
correct. IPs in the URL are not really an option. If scheme and host are
relevant, how can I inject them into the repository behind a reverse proxy
that uses virtual hosts?

Marc

Re: Secured reverse proxy for WebDav

Posted by Julian Reschke <ju...@gmx.de>.
Marc Speck wrote:
> Ah, got it. If this works, it's also a fine solution for me. The only reason
> I did not consider suggesting it was that I'm afraid of WebDav-clients
> incompatibility for relative paths in content. With my  limited experience

Absolute paths are fine. Many servers do that.

> ...

BR, Julian


Re: Secured reverse proxy for WebDav

Posted by Marc Speck <ma...@gmail.com>.
On Fri, Nov 14, 2008 at 4:30 PM, Julian Reschke <ju...@gmx.de>wrote:

> Marc Speck wrote:
>
>> What do you mean with "absolute paths inside <href> elements"? Could you
>> give me one hint more?
>>
>> Do you suggest to make hrefPrefixes a fixed configuration setting? In that
>> case I'd prefer a dynamic solution for handling virtual hosts.
>>
>
> I thought the issue where absolute URIs with incorrect hostnames in content
> (such as in multistatus). The simplest fix for that would be not to have the
> hostnames there in the first place.
>

Ah, got it. If this works, it's also a fine solution for me. The only reason
I did not consider suggesting it was that I'm afraid of WebDav-clients
incompatibility for relative paths in content. With my  limited experience
of WebDav-clients I'd say the quality of implementations varies greatly what
makes every change in the server behavior a major risk. If you are confident
that relative paths are fine for most clients (whatever that means), this is
a better solution.

Marc

Re: Secured reverse proxy for WebDav

Posted by Julian Reschke <ju...@gmx.de>.
Marc Speck wrote:
> What do you mean with "absolute paths inside <href> elements"? Could you
> give me one hint more?
> 
> Do you suggest to make hrefPrefixes a fixed configuration setting? In that
> case I'd prefer a dynamic solution for handling virtual hosts.

I thought the issue where absolute URIs with incorrect hostnames in 
content (such as in multistatus). The simplest fix for that would be not 
to have the hostnames there in the first place.

BR, Julian

Re: Secured reverse proxy for WebDav

Posted by Marc Speck <ma...@gmail.com>.
Hi Julian

On Thu, Nov 13, 2008 at 6:40 PM, Julian Reschke <ju...@gmx.de>wrote:

> Marc Speck wrote:
>
>> I want to reverse proxy webdav access with Apache 2.2. Besides routing and
>> other stuff, the web server also encrypts the connections. While this
>> works
>> fine with ProxyPass and ProxyPreserveHost for the host name, it fails for
>> sending the decrypted request from Apache to Jackrabbit. The reason is
>> that
>> Jackrabbit cannot know that it is supposed to deliver encrypted links in
>> his
>> responses.
>>
>> I think the problem/solution lies in the constructor of WebdavRequestImpl.
>> Instead of creating hrefPrefix in the constructor of WebdavRequestImpl,
>> could it be passed by the AbstractWebdavServlet.service() method? The
>> following change enables implementations of AbstractWebdavServlet to parse
>> their particular hrefPrefixes:
>> ...
>>
>
> Wouldn't it be much simpler just to put absolute paths inside the <href>
> elements?
>

What do you mean with "absolute paths inside <href> elements"? Could you
give me one hint more?

Do you suggest to make hrefPrefixes a fixed configuration setting? In that
case I'd prefer a dynamic solution for handling virtual hosts.

Thanks,
Marc

Re: Secured reverse proxy for WebDav

Posted by Julian Reschke <ju...@gmx.de>.
Marc Speck wrote:
> I want to reverse proxy webdav access with Apache 2.2. Besides routing and
> other stuff, the web server also encrypts the connections. While this works
> fine with ProxyPass and ProxyPreserveHost for the host name, it fails for
> sending the decrypted request from Apache to Jackrabbit. The reason is that
> Jackrabbit cannot know that it is supposed to deliver encrypted links in his
> responses.
> 
> I think the problem/solution lies in the constructor of WebdavRequestImpl.
> Instead of creating hrefPrefix in the constructor of WebdavRequestImpl,
> could it be passed by the AbstractWebdavServlet.service() method? The
> following change enables implementations of AbstractWebdavServlet to parse
> their particular hrefPrefixes:
> ...

Wouldn't it be much simpler just to put absolute paths inside the <href> 
elements?

BR, Julian