Orbeon and Reverse Proxy

Hello,

I have the following problem with our OPS application when I use it from
behind the reverse proxy.

We are using servlet context in the action attribute e.g.

<xforms:submission id="paging" ref="instance('main-instance')" method="post"
action="/codelists/paging" replace="instance" instance="main-instance"/>

The issue here is that the replace instance submissions are all executed on
the server making server-server posts but filling in the client server:port
URL part to complete the rest of the URL path. The problem is that the
client URL is not routable from within the server thus submissions fail.

We have fixed the issue by replacing all replace instance submission actions
using absolute action URL paths e.g.
<xforms:submission id="paging" ref="instance('main-instance')" method="post"
action="http://localhost:9080/app1/codelists/paging" replace="instance"
instance="main-instance"/>

This seems to work even though sometimes it appears that server session
handling is confused, which we fixed by moving the session to client (not
the best for what we need but works ok).

Now my question, is this the standard way of fixing this problem or is there
something better I can do?

Also, the same problem appeared even if the client URL is routable on the
server but when HTTPS is used as the server does not have the certificate
when making local calls.

-peter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Peter,

 > I have the following problem with our OPS application when I use it from
 > behind the reverse proxy.
 >
 > We are using servlet context in the action attribute e.g.
 >
 > <xforms:submission id="paging" ref="instance('main-instance')"
method="post"
 > action="/codelists/paging" replace="instance" instance="main-instance"/>
 >
 > The issue here is that the replace instance submissions are all
executed on
 > the server making server-server posts but filling in the client
server:port
 > URL part to complete the rest of the URL path. The problem is that the
 > client URL is not routable from within the server thus submissions fail.
 >
 > We have fixed the issue by replacing all replace instance submission
actions
 > using absolute action URL paths e.g.
 > <xforms:submission id="paging" ref="instance('main-instance')"
method="post"
 > action="http://localhost:9080/app1/codelists/paging" replace="instance"
 > instance="main-instance"/>
 >
 > This seems to work even though sometimes it appears that server session
 > handling is confused, which we fixed by moving the session to client (not
 > the best for what we need but works ok).

Client-side state handling may have a negative impact on performance
due to the size of the Ajax messages, but if it works for you then
great! You have probably seen this already but the doc discusses the
pros and cons here:

   http://www.orbeon.com/ops/doc/reference-xforms-ng#xforms-state-handling

As for losing the session, this may be a bug. The submission code by
defaults copies the JSESSIONID cookie, but this may or may not work
correctly depending on how the cookie is setup.

If you enable XForms logging, with the following:

   http://www.orbeon.com/ops/doc/reference-xforms-ng#xforms-debugging

then you should obtain some more detailed information about all the
steps occurring during submission. This may tell you something about
what goes wrong with the session.

 > Now my question, is this the standard way of fixing this problem or
is there
 > something better I can do?

If you have to use a different host/port to do submissions on the
server, I don't really see an alternative but to specify that
host/port in your XForms page. Not that it makes a big difference, but
you can also use xml:base with something like:

   <xforms:submission xml:base="http://localhost:9080/app1/"
                      action="codelists/paging" .../>

Also, you probably have a good reason not to allow accessing your host
name from the server, but if not you can fix it up in /etc/hosts or
equivalent.

 > Also, the same problem appeared even if the client URL is routable on the
 > server but when HTTPS is used as the server does not have the certificate
 > when making local calls.

You can set the SSL certificate in your Java VM, see this post:

   http://mail-archive.objectweb.org/ops-users/2006-10/msg00349.html

-Erik

--
Orbeon Forms - XForms Everywhere
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik,

I was just hoping there was a some global property I can set in a config
where it would have default xml:base for local submissions only since the
remote submissions have different xml:base... or do I want too much ;-)

-peter

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 30. novembra 2006 3:52
To: [hidden email]
Subject: Re: [ops-users] Orbeon and Reverse Proxy

Peter,

 > I have the following problem with our OPS application when I use it from
 > behind the reverse proxy.
 >
 > We are using servlet context in the action attribute e.g.
 >
 > <xforms:submission id="paging" ref="instance('main-instance')"
method="post"
 > action="/codelists/paging" replace="instance" instance="main-instance"/>
 >
 > The issue here is that the replace instance submissions are all
executed on
 > the server making server-server posts but filling in the client
server:port
 > URL part to complete the rest of the URL path. The problem is that the
 > client URL is not routable from within the server thus submissions fail.
 >
 > We have fixed the issue by replacing all replace instance submission
actions
 > using absolute action URL paths e.g.
 > <xforms:submission id="paging" ref="instance('main-instance')"
method="post"
 > action="http://localhost:9080/app1/codelists/paging" replace="instance"
 > instance="main-instance"/>
 >
 > This seems to work even though sometimes it appears that server session
 > handling is confused, which we fixed by moving the session to client (not
 > the best for what we need but works ok).

Client-side state handling may have a negative impact on performance
due to the size of the Ajax messages, but if it works for you then
great! You have probably seen this already but the doc discusses the
pros and cons here:

   http://www.orbeon.com/ops/doc/reference-xforms-ng#xforms-state-handling

As for losing the session, this may be a bug. The submission code by
defaults copies the JSESSIONID cookie, but this may or may not work
correctly depending on how the cookie is setup.

If you enable XForms logging, with the following:

   http://www.orbeon.com/ops/doc/reference-xforms-ng#xforms-debugging

then you should obtain some more detailed information about all the
steps occurring during submission. This may tell you something about
what goes wrong with the session.

 > Now my question, is this the standard way of fixing this problem or
is there
 > something better I can do?

If you have to use a different host/port to do submissions on the
server, I don't really see an alternative but to specify that
host/port in your XForms page. Not that it makes a big difference, but
you can also use xml:base with something like:

   <xforms:submission xml:base="http://localhost:9080/app1/"
                      action="codelists/paging" .../>

Also, you probably have a good reason not to allow accessing your host
name from the server, but if not you can fix it up in /etc/hosts or
equivalent.

 > Also, the same problem appeared even if the client URL is routable on the
 > server but when HTTPS is used as the server does not have the certificate
 > when making local calls.

You can set the SSL certificate in your Java VM, see this post:

   http://mail-archive.objectweb.org/ops-users/2006-10/msg00349.html

-Erik

--
Orbeon Forms - XForms Everywhere
http://www.orbeon.com/blog/






--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Peter,

Something like this  would certainly be possible, but it's probably the
first time we see this particular use case ;-)

I am also wondering if a global property wouldn't be "too global" for this.

-Erik

Peter Kolarov wrote: --
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik,

Thats interesting that I am the only one with this issue, I would think that
it  would be quite common in enterprise deployments where you have DMZ HTTP
server / access manager and firewalls configured in such a way that external
URLs are not routable from within the application server (this is our
customer's case), also when you use HTTPS for the remote POSTs I would think
it would be waste to use it for submissions executed locally
server-to-server, dont you thinks so?

-peter

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 7. decembra 2006 0:59
To: [hidden email]
Subject: Re: [ops-users] Orbeon and Reverse Proxy

Peter,

Something like this  would certainly be possible, but it's probably the
first time we see this particular use case ;-)

I am also wondering if a global property wouldn't be "too global" for this.

-Erik

Peter Kolarov wrote: instance="main-instance"/>
>  >
>  > The issue here is that the replace instance submissions are all
> executed on
>  > the server making server-server posts but filling in the client
> server:port
>  > URL part to complete the rest of the URL path. The problem is that the
>  > client URL is not routable from within the server thus submissions
fail. certificate
>  > when making local calls.
>
> You can set the SSL certificate in your Java VM, see this post:
>
>    http://mail-archive.objectweb.org/ops-users/2006-10/msg00349.html
>
> -Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/






--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws