JavaScript in mashup calls from the same server as the Web Player does not compromise domain security. If the mashup and the Web Player reside on different servers, attention to domain attributes is essential.
Overview
This tutorial is applicable if the mashup is deployed to a server
other than the Web Player server. When a mashup makes JavaScript
calls to a Web Player application located in another frame on
a web page, browsers prohibit the interaction unless the JavaScript
comes from the same server. Browsers today prohibit cross-site
scripting (XSS).
One solution to this cross-site scripting problem can be implemented
directly in the pages or scripts. Set the domain attribute of
the two DOM documents to the same domain name. This solution
comes with one restriction: a page can only change its domain
attribute to a parent domain of itself.
- A script from
machine1.department1.company.com
defaults it’s domain attribute to machine1.department1.company.com.
The script can set its domain attribute to department1.company.com
or company.com.
- A script from
machine1.department1.company.com
cannot change the domain value to machine2.department1.company.com
or department2.company.com, not even company2.com.
If the domain attribute of the Web Player/mashup application
is changed, all users of that server must use fully qualified
domain name when browsing the mashup, like http://machine1.department1.company.com/Mashup/.
Fully qualified domain names must also be used by all users
of the Web Player application, in this case something like
http://machine2.department1.company.com/SpotfireWeb/.
The bottom line is that the domain path of the server must end
with the chosen domain attribute path: department1.company.com.
For more information about the cross site scripting refer to
Cross-Site Scripting in Wikipedia, About Cross-Frame Scripting
and Security in MSDN, and Ajax and Mashup Security
at OpenAjax alliance.
Server Configuration Example
Suppose the simple SpotfireDeveloper.WebAutomationExample\Demo2.htm
mashup in the SDK is deployed to the server MashupSrv.example.com.
Then consider the distributed client/server, Web Player/mashup
scenario:
This example indicates the changes required to
- Open the
Web.config file on the WebPlayerSrv.example.com
Web Player server.
It is usually located in C:\Program Files\TIBCO\Spotfire Web
Player\2.1\webroot.
- Locate the
setup section, add the <javaScriptApi...>
line setting the domain attribute to
the domain of the servers, and save:
<!-- ******************** WEB PLAYER SETTINGS ...***** -->
<spotfire.dxp.web>
<!-- ****************** Web Player settings for non visible items -->
<setup>
<javaScriptApi enabled="true" domain="example.com" />
<!-- The mailto link on the error ...
You can also set the maximum length of the email -->
<errorReporting emailAddress="admin@example.com" />
- Open the
Demo2.htm mashup example file on the
MashupSrv.example.com mashup server,
locate the <script> section,
change the web player server paths to http://WebPlayerSrv.example.com/SpotfireWeb/,
and change the domain attribute to example.com:
<script type="text/javascript"
src="http://WebPlayerSrv.example.com/SpotfireWeb/GetJavaScriptApi...."> <!-- CHANGE -->
</script>
<script type="text/javascript" src="Scripts/util.js"></script>
<script type="text/javascript">
// If you run the this file on another web server than the Web...,
// you need to change this property. See Web Player JavaScript ...
document.domain = "example.com"; // CHANGE
//
// Constants
//
var c_serverUrl = "http://WebPlayerSrv.example.com/SpotfireWeb/"; // CHANGE
var c_analysisPath = "TIBCO Spotfire Example Files/MedicalPerfo...";
var c_majorRegions = ["(All)", "MW", "NE", "SE", "WE", "(None)"];
If the demo file is not part of web application, create the web
application/virtual directory on the MashupSrv:
- Users access the mashup URL
http://MashupSrv.example.com/[web
application]/Demo2.htm
- Users browse the Web Player server using the URL
http://WebPlayerSrv.example.com/SpotfireWeb/.
If you make these changes to an existing Web Player site, remember
to inform users about the new URL, unless they already the access
it by the fully qualified URLs.
Debugging
To develop mashups without installing the Web Player on the development
machine, perform the changes above, replacing the name of the
mashup server with the one of the development machine.
- Always use qualified domain names when debugging or testing,
like
http://developmentmachine.example.com /SpotfireWebSdkExamples/.
- Do NOT use URLs like
http://localhost/... or
http://developmentmachine/...
Other Mashup Sources
If the mashup interacts with JavaScript from another server located
in its own IFRAME tag, that server must set the
same common domain name.
This does not apply to applications like Microsoft® Virtual
Earth, Google Maps or Yahoo!®
Maps, since they add content to <div>
tags rather than IFRAME tags.