DWR 3 M1: dwr/call/plaincall/__System.pageLoaded.dwr on "wrong" port/server

[Jochen Huber]

Hello,

in my current setup, I'm _required_ to have a different server than my application server serve HTML files. Let's say web-pages are being served from an Apache on IP A and DWR runs on a Tomcat on IP B.

What I usually did with DWR2 was to include <script> references to engine.js on IP B (and other classes, respectively) within web-pages served from the Apache on IP A. This worked out perfectly alright.

Let's say an Apache runs on 127.0.0.1 Port 8000. A Tomcat, serving the dwr scripts, runs on 127.0.0.1 Port 8080. Thus I would include

<script type='text/javascript' src='http://127.0.0.1:8080/web/dwr/interface/CollaborationManager.js'></script>

in web-pages served from the web-server. As a matter of fact (with DWR 3 M1) this results in the following post request

POST http://127.0.0.1:8000/web/dwr/call/plaincall/__System.pageLoaded.dwr

which fails due to the fact of DWR being located on 127.0.0.1:8080, not on 8000. Consequently, DWR scripts cannot be executed.

Any ideas would be appreciated :)

[David Marginian-2]

There are numerous ways to forward requests from apache to tomcat.  I
recommend taking a look on the web.  Here is an example:
http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp

Jochen Huber wrote:

> Hello,
>
> in my current setup, I'm _required_ to have a different server than my
> application server serve HTML files. Let's say web-pages are being served
> from an Apache on IP A and DWR runs on a Tomcat on IP B.
>
> What I usually did with DWR2 was to include <script> references to engine.js
> on IP B (and other classes, respectively) within web-pages served from the
> Apache on IP A. This worked out perfectly alright.
>
> Let's say an Apache runs on 127.0.0.1 Port 8000. A Tomcat, serving the dwr
> scripts, runs on 127.0.0.1 Port 8080. Thus I would include
>
> <script type='text/javascript'
> src='http://127.0.0.1:8080/web/dwr/interface/CollaborationManager.js'></script>
>
> in web-pages served from the web-server. As a matter of fact (with DWR 3 M1)
> this results in the following post request
>
> POST http://127.0.0.1:8000/web/dwr/call/plaincall/__System.pageLoaded.dwr
>
> which fails due to the fact of DWR being located on 127.0.0.1:8080, not on
> 8000. Consequently, DWR scripts cannot be executed.
>
> Any ideas would be appreciated :)
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Huber]

David,

thank you very much for your really fast answers throughout the day. :)

Unfortunately I cannot forward the requests from apache to tomcat. I cannot manipulate/re-configure the web server :(

David Marginian-2 wrote:

There are numerous ways to forward requests from apache to tomcat.  I
recommend taking a look on the web.  Here is an example:
http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp

Jochen Huber wrote:
> Hello,
>
> in my current setup, I'm _required_ to have a different server than my
> application server serve HTML files. Let's say web-pages are being served
> from an Apache on IP A and DWR runs on a Tomcat on IP B.
>
> What I usually did with DWR2 was to include <script> references to engine.js
> on IP B (and other classes, respectively) within web-pages served from the
> Apache on IP A. This worked out perfectly alright.
>
> Let's say an Apache runs on 127.0.0.1 Port 8000. A Tomcat, serving the dwr
> scripts, runs on 127.0.0.1 Port 8080. Thus I would include
>
> <script type='text/javascript'
> src='http://127.0.0.1:8080/web/dwr/interface/CollaborationManager.js'></script>
>
> in web-pages served from the web-server. As a matter of fact (with DWR 3 M1)
> this results in the following post request
>
> POST http://127.0.0.1:8000/web/dwr/call/plaincall/__System.pageLoaded.dwr
>
> which fails due to the fact of DWR being located on 127.0.0.1:8080, not on
> 8000. Consequently, DWR scripts cannot be executed.
>
> Any ideas would be appreciated :)
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[David Marginian-2]

Bummer, you're welcome too bad I haven't been very helpful.

DefaultRemoter has a method called getPathToDwrServlet.  It uses the
information from the request to construct a path to the dwr servlet.  
This path is injected into the generated engine.js as
dwr.engine._pathToDwrServlet which is why you are seeing the port being
replaced.  I know other people have overrode the
dwr.engine._pathToDwrServlet variable successfully (although kind of a
hack).

Try something like:
dwr.engine._pathToDwrServlet = "whatever it should be";

Hope this helps.



Jochen Huber wrote:

> David,
>
> thank you very much for your really fast answers throughout the day. :)
>
> Unfortunately I cannot forward the requests from apache to tomcat. I cannot
> manipulate/re-configure the web server :(
>
>
>
> David Marginian-2 wrote:
>  
>> There are numerous ways to forward requests from apache to tomcat.  I
>> recommend taking a look on the web.  Here is an example:
>> http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp
>>
>> Jochen Huber wrote:
>>    
>>> Hello,
>>>
>>> in my current setup, I'm _required_ to have a different server than my
>>> application server serve HTML files. Let's say web-pages are being served
>>> from an Apache on IP A and DWR runs on a Tomcat on IP B.
>>>
>>> What I usually did with DWR2 was to include <script> references to
>>> engine.js
>>> on IP B (and other classes, respectively) within web-pages served from
>>> the
>>> Apache on IP A. This worked out perfectly alright.
>>>
>>> Let's say an Apache runs on 127.0.0.1 Port 8000. A Tomcat, serving the
>>> dwr
>>> scripts, runs on 127.0.0.1 Port 8080. Thus I would include
>>>
>>> <script type='text/javascript'
>>> src='http://127.0.0.1:8080/web/dwr/interface/CollaborationManager.js'></script>
>>>
>>> in web-pages served from the web-server. As a matter of fact (with DWR 3
>>> M1)
>>> this results in the following post request
>>>
>>> POST http://127.0.0.1:8000/web/dwr/call/plaincall/__System.pageLoaded.dwr
>>>
>>> which fails due to the fact of DWR being located on 127.0.0.1:8080, not
>>> on
>>> 8000. Consequently, DWR scripts cannot be executed.
>>>
>>> Any ideas would be appreciated :)
>>>  
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Huber]

I've tried to manipulate both dwr.engine._defaultPath and dwr.engine._pathToDwrServlet. Well, guess what: variables are set correctly (checked it with Firebug) but without any effect.

Due to the false post request, I'm not able to execute any DWR scripts. I'll have to switch back to 2.0.5 which leads me to my old problem of not being able to transfer DOM objects properly. :(

David Marginian-2 wrote:

Bummer, you're welcome too bad I haven't been very helpful.

DefaultRemoter has a method called getPathToDwrServlet.  It uses the
information from the request to construct a path to the dwr servlet.  
This path is injected into the generated engine.js as
dwr.engine._pathToDwrServlet which is why you are seeing the port being
replaced.  I know other people have overrode the
dwr.engine._pathToDwrServlet variable successfully (although kind of a
hack).

Try something like:
dwr.engine._pathToDwrServlet = "whatever it should be";

Hope this helps.

[Jochen Huber]

I just a found an interesting part in engine.js:

 /** These URLs can be configured from the server */
252 dwr.engine._ModePlainCall = "/call/plaincall/";
253 dwr.engine._ModePlainPoll = "/call/plainpoll/";
254 dwr.engine._ModeHtmlCall = "/call/htmlcall/";
255 dwr.engine._ModeHtmlPoll = "/call/htmlpoll/";

How can theses URLs be configured from the server? Setting them to the absolute URL should solve my problem.




I've tried to manipulate both dwr.engine._defaultPath and dwr.engine._pathToDwrServlet. Well, guess what: variables are set correctly (checked it with Firebug) but without any effect.

Due to the false post request, I'm not able to execute any DWR scripts. I'll have to switch back to 2.0.5 which leads me to my old problem of not being able to transfer DOM objects properly. :(

David Marginian-2 wrote:

Bummer, you're welcome too bad I haven't been very helpful.

DefaultRemoter has a method called getPathToDwrServlet.  It uses the
information from the request to construct a path to the dwr servlet.  
This path is injected into the generated engine.js as
dwr.engine._pathToDwrServlet which is why you are seeing the port being
replaced.  I know other people have overrode the
dwr.engine._pathToDwrServlet variable successfully (although kind of a
hack).

Try something like:
dwr.engine._pathToDwrServlet = "whatever it should be";

Hope this helps.

[David Marginian-2]

They are in a config file called defaults.properties.

Jochen Huber wrote:

> I just a found an interesting part in engine.js:
>
>  /** These URLs can be configured from the server */
> 252 dwr.engine._ModePlainCall = "/call/plaincall/";
> 253 dwr.engine._ModePlainPoll = "/call/plainpoll/";
> 254 dwr.engine._ModeHtmlCall = "/call/htmlcall/";
> 255 dwr.engine._ModeHtmlPoll = "/call/htmlpoll/";
>
> How can theses URLs be configured from the server? Setting them to the
> absolute URL should solve my problem.
>
>
>
>
> Jochen Huber wrote:
>  
>> I've tried to manipulate both dwr.engine._defaultPath and
>> dwr.engine._pathToDwrServlet. Well, guess what: variables are set
>> correctly (checked it with Firebug) but without any effect.
>>
>> Due to the false post request, I'm not able to execute any DWR scripts.
>> I'll have to switch back to 2.0.5 which leads me to my old problem of not
>> being able to transfer DOM objects properly. :(
>>
>>
>> David Marginian-2 wrote:
>>    
>>> Bummer, you're welcome too bad I haven't been very helpful.
>>>
>>> DefaultRemoter has a method called getPathToDwrServlet.  It uses the
>>> information from the request to construct a path to the dwr servlet.  
>>> This path is injected into the generated engine.js as
>>> dwr.engine._pathToDwrServlet which is why you are seeing the port being
>>> replaced.  I know other people have overrode the
>>> dwr.engine._pathToDwrServlet variable successfully (although kind of a
>>> hack).
>>>
>>> Try something like:
>>> dwr.engine._pathToDwrServlet = "whatever it should be";
>>>
>>> Hope this helps.
>>>
>>>      
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Huber]

Thanks,

I cached engine.js and changed the paths in this file directly. It does work as long as both servers run on the same IP. When the IP differs, I get a cross-domain exception. Nevertheless, including DWR scripts located on a different server worked in DWR 2.0.x.

So here's my (final) question: Why has the code been changed? ;)

David Marginian-2 wrote:

They are in a config file called defaults.properties.

[David Marginian-2]

I don't know the exact reasons but a lot of improvements have been made
in 3.0.  Obviously, the cross-domain feature is there for security
purposes but it can be configured:
http://directwebremoting.org/dwr/server/servlet.

The bottom-line is that what you are doing is far from a typical use
case.  Most users would configure apache to forward the requests to
tomcat and be done with it (no DWR changes necessary).

There may be a better way to accomplish what you need but we'll have to
wait for someone on the list who knows more than me.

Jochen Huber wrote:

> Thanks,
>
> I cached engine.js and changed the paths in this file directly. It does work
> as long as both servers run on the same IP. When the IP differs, I get a
> cross-domain exception. Nevertheless, including DWR scripts located on a
> different server worked in DWR 2.0.x.
>
> So here's my (final) question: Why has the code been changed? ;)
>
>
> David Marginian-2 wrote:
>  
>> They are in a config file called defaults.properties.
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Huber]

I've already configured the cross-domain feature and set the crossDomainSessionSecurity to false. Without this being set to false, I wouldn't have been able to use my scripts in the setup mentioned above with DWR 2.0.x. In DWR 2.0.x, I set the _path for every remote object to the absolute path to the scripts on the Tomcat.

Perhaps a member of the dev team can bring light into this...

David Marginian-2 wrote:

I don't know the exact reasons but a lot of improvements have been made
in 3.0.  Obviously, the cross-domain feature is there for security
purposes but it can be configured:
http://directwebremoting.org/dwr/server/servlet.

The bottom-line is that what you are doing is far from a typical use
case.  Most users would configure apache to forward the requests to
tomcat and be done with it (no DWR changes necessary).

There may be a better way to accomplish what you need but we'll have to
wait for someone on the list who knows more than me.

[David Marginian-2]

So you are still having a problem because of the
crossDomainSessionSecurity exception?

I don't see how this is happening if you have the
crossDomainSessionSecurity disabled.  I would put a breakpoint in
BaseDwrpHandler.checkNotCsrfAttack.  That is the only place that
exception is thrown and if you look at the method I don't see how it can
be thrown if you have set crossDomainSessionSecurity to false.

Jochen Huber wrote:Jochen Huber wrote:

> I've already configured the cross-domain feature and set the
> crossDomainSessionSecurity to false. Without this being set to false, I
> wouldn't have been able to use my scripts in the setup mentioned above with
> DWR 2.0.x. In DWR 2.0.x, I set the _path for every remote object to the
> absolute path to the scripts on the Tomcat.
>
> Perhaps a member of the dev team can bring light into this...
>
>
> David Marginian-2 wrote:
>  
>> I don't know the exact reasons but a lot of improvements have been made
>> in 3.0.  Obviously, the cross-domain feature is there for security
>> purposes but it can be configured:
>> http://directwebremoting.org/dwr/server/servlet.
>>
>> The bottom-line is that what you are doing is far from a typical use
>> case.  Most users would configure apache to forward the requests to
>> tomcat and be done with it (no DWR changes necessary).
>>
>> There may be a better way to accomplish what you need but we'll have to
>> wait for someone on the list who knows more than me.
>>
>>    

> I've already configured the cross-domain feature and set the
> crossDomainSessionSecurity to false. Without this being set to false, I
> wouldn't have been able to use my scripts in the setup mentioned above with
> DWR 2.0.x. In DWR 2.0.x, I set the _path for every remote object to the
> absolute path to the scripts on the Tomcat.
>
> Perhaps a member of the dev team can bring light into this...
>
>
> David Marginian-2 wrote:
>  
>> I don't know the exact reasons but a lot of improvements have been made
>> in 3.0.  Obviously, the cross-domain feature is there for security
>> purposes but it can be configured:
>> http://directwebremoting.org/dwr/server/servlet.
>>
>> The bottom-line is that what you are doing is far from a typical use
>> case.  Most users would configure apache to forward the requests to
>> tomcat and be done with it (no DWR changes necessary).
>>
>> There may be a better way to accomplish what you need but we'll have to
>> wait for someone on the list who knows more than me.
>>
>>    

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Huber]

Trying to catch up with this:

crossDomainSessionSecurity is indeed set to false.

The thing I do _not_ get is that DWR tries to call plaincall/__System.pageLoaded.dwr on e.g. 127.0.0.1:8000 whereas it should call it on 127.0.0.1:8080, where engine.js etc are hosted. This bevaviour is totally new since DWR 3.0 M1.

Thanks
Jochen

David Marginian-2 wrote:

So you are still having a problem because of the
crossDomainSessionSecurity exception?

I don't see how this is happening if you have the
crossDomainSessionSecurity disabled.  I would put a breakpoint in
BaseDwrpHandler.checkNotCsrfAttack.  That is the only place that
exception is thrown and if you look at the method I don't see how it can
be thrown if you have set crossDomainSessionSecurity to false.

[Jochen Huber]

__System.pageLoaded.dwr is called through

  // Fetch the scriptSessionId from the server
  dwr.engine._execute(dwr.engine._defaultPath, '__System', 'pageLoaded', function() {
    dwr.engine._ordered = false;
  });

which is located in engine.js. Manipulating the dwr.engine._defaultPath results in a cross-domain error because (in my setup which _cannot_ be altered) application server and web server are located on different machines, i.e. IPs. This cross-domain error is not issued by DWR or through DWR. It's caused by the request which is to be sent.

As a matter of fact this was not a problem in DWR 2.

I'm really stuck. Any hints? I don't want to downgrade to DWR 2 :(



Trying to catch up with this:

crossDomainSessionSecurity is indeed set to false.

The thing I do _not_ get is that DWR tries to call plaincall/__System.pageLoaded.dwr on e.g. 127.0.0.1:8000 whereas it should call it on 127.0.0.1:8080, where engine.js etc are hosted. This bevaviour is totally new since DWR 3.0 M1.

Thanks
Jochen

David Marginian-2 wrote:

So you are still having a problem because of the
crossDomainSessionSecurity exception?

I don't see how this is happening if you have the
crossDomainSessionSecurity disabled.  I would put a breakpoint in
BaseDwrpHandler.checkNotCsrfAttack.  That is the only place that
exception is thrown and if you look at the method I don't see how it can
be thrown if you have set crossDomainSessionSecurity to false.