// you’re reading...


Getting a Page Preview from outside the CMS

This blog post is inspired by “Shawn”.  Hope this helps.

Some background first I think.  There are 2 ways to log in to CMS – normal and integrated.  An integrated login means that your Windows user account is passed silently by your browser to the CMS server and you don’t need to type in a username or password.  If you’re organisation uses Windows and you aren’t using integrated login slap yourself across the face now for being lazy, then read up on how to configure it.  Your users will thank you tomorrow.  It takes about 10 minutes to set up and is much better for security (since it’s harder to forge).  If you are using integrated login already this is super-easy and you’re probably wondering why I’m bothering to blog about this at all.  If you’re reading this, therefore, it stands to reason that you’re not.

I am going to assume that you, reader, already has the capabilities required to locate the GUID of the page you want a preview of.  In some cases you will require the LinkFromGuid as well to provide CMS with the context it needs to render the page properly.  I have had success with the following minimalist URL:


[If you use Action=Preview it will work without the Mode parameter]
[If you have lots of projects you should send the ProjectGuid parameter too]

If you want the full thing for your case simply pop a preview window, right-click the page and hit Properties.  Triple-click (yes, you read that right) on the URL to select even the bits that fall off the screen and you can copy/paste into your editor of choice.

There are 3 approaches…

1. RQL => Hard

You can use the following RQL to get the preview HTML of a CMS page:

<IODATA loginguid="[LoginGuid]" sessionkey="[SessionKey]"> <PREVIEW mode="0" projectguid="[ProjectGuid]" versionguid="[VersionGuid]"    isolated="[Isolated]" generatedate="[AsAtDate]"    templateguid="[templateGuid]" rights1="[UserRights]"    loginguid="[LoginGuid]" url="[URL]"    querystring="[QueryStringParams]"    />

This is hard for a few reasons.  Firstly there is quite a lot of information you are going to need to create an RQL like this, not least of which you are going to have to login to the RQL system which will require credentials and you may not want to ask your user for them.  This is where integrated login comes in.  With it you can use the Windows Integrated Login system so you can get your user into RQL without requiring a username and password for them [read how to do it here].  Otherwise just form the normal RQL login tags with a username and password.  The second problem is that while this will return you the HTML of the preview it will provide no assistance in rendering, so you will need to re-map all the image placeholders and probably generate a bunch more pages for JavaScript and CSS (assuming they are built off Content Classes and not just stored in the Asset library).  That is definitely the hard way.

2. Integrated Login => Super Easy

Simply point your user at the URL.  Since the browser and RedDot do the login in the background it should just work.  Assuming you already have the GUIDs you need from somewhere else.  If not, you first need to run some RQL to get them.  This is where the Integrated Login plugin I talked about before comes in handy.  Using that you can silently log your user into RQL, execute whatever steps are required to get your GUIDs, and redirect the user to the correct URL.  Job done.

3. Standard Login => Moderate

The problem here is that you need to get credentials off your user.  If you don’t log your session in to RedDot you will get a nasty error message when you launch the preview URL to the effect that LogonGuid and SessionKey are missing.  That’s because these are server variables that RedDot is expecting to have when it attempts to generate the preview.  The only way forward is to get them, and that means logging in.

You need to do this in ASP because we need to set Session variables for the CMS to use. It is possible to get/set session variables with other languages but it’s way harder than if you just use ASP.  Here are the steps to follow:

  • Create a new plugin ASP page – this is the page you will call to perform all the tasks required to access the preview
    • On the first pass of the page show login username and password boxes for the user to complete
    • On the second pass use that information to form the login RQL command
    • Do other steps to get the GUIDs you need to form the preview URL – this may include asking the user for more information, or you could supply it as parameters in the originally called URL
    • Redirect the user to the preview URL
  • Set your external app to call your plugin with the correct parameters
  • Since you’re not calling this plugin from CMS’ SmartTree/SmartEdit there is no need to register it in the normal way.

The reason we do it as a plugin is that plugins run within the application scope of the CMS.  That means session data stored in a plug is available to the main CMS, including the LogonGuid and SessionKey that get generated as part of the RQL login process.  We can save these to Session variables so the preview page can get at them.

You can download a sample ASP file here.

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Richard Hauer Richard is a Solution Architect with 5 Limes in Sydney, Australia. Richard has delivered CRM, .Net and RedDot solutions to many household name companies including Microsoft, Coca-Cola, Rothmans, Nestle, Tourism Australia, Network TEN, Australian Wool, Panasonic, the Royal Agricultural Society, Perpetual, and Challenger.


5 comments for “Getting a Page Preview from outside the CMS”

  1. If you want notes on how to set up integrated login in CMS leave me a comment – if I get a few I’ll blog that too.

    Posted by Richard Hauer | December 5, 2009, 12:20 pm
  2. This is fantastic stuff, and works very well. but now let’s take it a step further and say:

    Using the same process, how can we get reddot to invoke redlining function on a page and return that ?

    Posted by Shawn | December 5, 2009, 11:05 pm
  3. Invoking the redlining feature seems to be much the same process except the final URL you redirect to is different. Initial investigations point to a URL like this:


    Looks pretty straight forward. There is RQL you can use to get all the versions of a page:

    <IOATA loginguid=”[LoginGuid]” sessionkey=”[SessionKey]“> <VERSIONS action=”list” pageguid=”[PageGuid]” datebegin=”[StartDate]” type=”page” /> </IODATA>

    There are a few other Session variables that you will need to set before this will work. In redlining te diff is actually performed by a separate application. CMS writes some temp files, calles the diff tool and renders the result. We have had some problems whn the diff tool encounters CSS which is why redlining often fails on pages that are rendering stylesheets. Anyway, the session variables you’ll need are as follows:

       Session(”HttpDir”) = “http://rd/CMS/”
       Session(”TempDir”) = “C:\Program Files\Open Text\WS\MS\ASP\RedDotTemp\[SessionKey]\”

    Update as appropriate to your install of course. The next problem is that the “TempDir” folder has to exist or the whoe thing dies. Normally CMS would create this for you automatically but it doesn’t seem to do so when you log in via RQL. A few more lines of code sorts this out:

       ’Ensure session temp folder
       set fso = Server.CreateObject(”Scripting.FileSystemObject”)
       If Not fso.FolderExists( Session(”TempDir”) ) Then fso.CreateFolder( Session(”TempDir”) )
       set fso = Nothing

    CMS has some built-in cleanup routines that seem to wash away these temp dir’s periodically without help (at least I’ve seen them disappear without me deleting them). Best keep an eye on it anyway or there’ll be a truckload of them soon enough.

    I have updated the Preview.zip file download (linked above) to incorporate the new variables and the redlining URL.

    Posted by Richard Hauer | December 6, 2009, 8:42 am
  4. WARNING: Have been experimenting with this a little on a project and I have discovered that you shouldn’t use these functions from a non-RedDot process during the processing of another page. Example: a RedDot page contains a .Net user control which calls the preview of a page designed to emit an XML file. If the .Net user control uses the same login details as the RedDot page that called it (which can happen with integrated login) then it seems some session variables get screwed up in RedDot and the main page – the one containing the .Net control – never finishes. It does work if you give the .Net app a forced principal (in the web.config file) with logon privileges of its own that are different to the ones the user is connected with. Hope that makes sense.

    Posted by Richard Hauer | December 20, 2009, 8:30 am
  5. Thanks for the update. :)

    Posted by Shawn | December 20, 2009, 8:31 pm

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...