CSP Gateway Configuration Guide - InterSystems Documentation

CSP with Microsoft Active Server Pages (ASP) and VBScript
2.8 CSP with Microsoft Active Server Pages (ASP) and
VBScript
You can mix CSP pages with ASP pages and vice versa provided the integrity of the user's session is maintained for both
environments. Both environments maintain their sessions using identifiers stored in cookies. CSP stores its session ID in
a cookie named with a prefix of CSPSESSIONID and ASP uses a cookie named with a prefix of ASPSESSIONID.
For example:
CSPSESSIONID=00200001000614eX37yi00363806761900000000000000000000000000
ASPSESSIONIDCCATBQCQ=DPLBEBECJLCJKIHKIKEFCCOA
Provided the session ID for each environment is protected when serving pages from the other environment, the application
should be able to seamlessly and transparently swap between CSP and ASP based applications.
2.8.1 Client-side VBScript in CSP
VBScript, to be executed in the client’s Internet Explorer environment, can be added to CSP pages in the same way that
JavaScript is used.
For example:
document.write "The time is: ",time
2.8.2 Server-side VB-Script in CSP (Serving ASP Content through CSP)
Sometimes you want to construct and serve complete ASP pages from a CSP application. In this case, the pages generated
by CSP contain VBScript that is executed on the web server host (in the ASP engine) as opposed to in the client’s browser.
The ASP (and ASP.NET) engine, in common with the CSP Gateway, is implemented as an ISAPI extension to IIS. However,
there is no mechanism through which the CSP Gateway can route ASP content generated by CSP ‘sideways’ through the
ASP engine.
The facility for serving ASP content through CSP is implemented in the CSP Gateway by saving the ASP page returned
by CSP as a physical file under the IIS documents root. Having done this, the client is then redirected to that page. The
second redirection step results in the newly created ASP page being processed by the ASP engine, at which point the serverside
VBScript is executed before the final page is delivered to the client.
The CSP Gateway manages the redirection to the ASP resource in one of two ways.
• Server-side redirection This is the preferred choice. The CSP Gateway, having saved the ASP content returned
from CSP as a temporary ASP file, simply requests the page through IIS. IIS ensures that that page is processed by
the ASP engine and the content is delivered to the client. The temporary ASP page is then deleted. The advantage of
this approach is that, from the client’s perspective, it appears as if the ASP content is served directly from CSP. The
original CSP page requested is registered in the browser’s ‘address’ box.
• Client-side redirection In this scenario, the Gateway redirects the client to the newly-created ASP resource
by sending an HTTP redirection header to the client. It is necessary to use this option if SSL is used between the client
and web server. The main disadvantage of this method, apart from the extra round-trip to the client, is that the URL
to the temporary ASP page is registered in the browser’s address box. This means that the client must be able to rerequest
the temporary ASP resource (either as a result of users pressing the Refresh button or using the back-button
against a later page). In order to facilitate this requirement, the Gateway retains temporary ASP files for 24 hours after
they have been created.
CSP Gateway Configuration Guide 47