Questions & Answers

[seth_w_jackson]

Hi everyone,

Server version: 5.2.212.71463

While using the ContentCreator, I configured the generation channel to request from my offline application server with an additional request parameter. In my JSPs, this request parameter causes an HTML comment to be written to the page, which I then find and replace within the generation channel. This is how I inject the content from FirstSpirit into the live request from the application server.

However, one issue I can't solve is the utilization of Dojo. Since my application includes Dojo libraries, Chrome blocks the execution of this javascript in ContentCreator for reasons of cross site scripting potentials.

I currently set my fs-server.conf to include:

allowedRedirectHosts=ALLOW_ALL

But this didn't help.

Is my only other option to host these libraries on the CMS server itself to prevent XSS errors?

Thank you,

Seth Jackson

[kscheuing]

If i get you correctly, you add an request parameter (url or http ?!) to your communication between browser and applicationserver or the other way around ?

Is it an Tomcat ? How is it technically realized ? some more information on that please..

In general, your used js library should be accessable from the page you request it from, you considert about this?

can you tell where that cross site scripting error comes from ?

best, kai

[rschulz]

You might want to consider a different setup with a reverse proxy like nginx as the web-facing component and your application server behind it. Static files can then be delivered via nginx. Other requests can be proxied through to your application server. All delivered content will originate from the same source so that the same origin policy /xss protection should no longer block your javascript.

[seth_w_jackson]

I guess I'm a little confused on how the reverse proxy logical diagram would look.

All of the JS from the application uses relative pathing (e.g. <script src="/js/dojo/etc.js"/>)

So when the preview render template executes, it replaces "/js" with "dev.mydomain.com/js" so it can resolve the resources. This is the same case with all JS, CSS, images, etc.

However, as noted, when doing this with the DOJO library, XSS is encountered. I could host the DOJO libraries on the CMS server but I'd prefer not to if I can help it.

[rschulz · Accepted solution]

I am assuming that you have two servers, where one hosts the firstspirit instance (fs-server), and one hosts the static javascript (js-server) files. The relational urls do not work in the fs templates as the files are not hosted on the fs-server.
An absolute path to a different server only works if the CORS related headers are properly set in server responses (Access-Control-* headers).

Instead of setting these headers you could hide both servers behind a proxy (which could be installed on either of the two servers). If nginx is installed on the fs-server, then a pseudo nginx config could look like the one below.

location /static/js {

  proxy_pass http://js-server;

}

location / {

  proxy_pass http://localhost:8000;

}

As a result requests to any location except for those starting with "/static/js" will be proxied through to the firstspirit instance. All requests starting with /static/js will be proxied through to the js-server. If the content creator is accessed through nginx, then no changes need to be made to the relative paths in the templates as all requests are eventually served from the same server.

So you have the choice between hosting static files on the fs-server, setting up CORS or using a reverse proxy like nginx.

[tenter]

Hi Seth,

Rocco's suggestions seem to make sense for me, while setting up the correct headers would probably be the simplest solution to your problem. Did you already try that now?

By the way, is there any particular reason why you want to host dojo on your offline application server? Even though I don't know the actual size of the library, I doubt it is that much larger than the size of a jQuery, ember or other common js libraries you probably use.

I don't know if it's recommandable for your case, but you could also deactivate the same-origin-policy of your chrome, if it's only for your local development. That might solve your problem, if I got it right.

Thanks,

Hannes

[pavone]

Hello Seth,   

do you need further help or did one of the given replies already help you? If so, it would be great if you marked that reply as "correct answer" so that other community users find the solution easily. If you have already found a solution by yourself, it would be very kind of you, if you posted it here.

Best regards 

Tim