Archive for September, 2012

Prevent Session Timeouts

Monday, September 24th, 2012

We ran into a problem recently where one of our web applications, Frevvo, was timing out. Because Frevvo is a form building tool and we were conducting an extensive survey, occasionally users would take longer than the standard 15-minute session timeout interval. Consequently, when they submitted the survey, the web app wasn’t able to to reconcile the browser’s cookie with a server-side session, and the submission failed – resulting in a lost survey response and unhappy users.

One option was to increase the session time-out, but that could have resulted in wasted resources for users who had already closed their browser windows. Instead, we wanted users with their browser windows still open to keep their session indefinitely, while others would safely close and conserve server resources. To accomplish this, we used the following JavaScript to ensure that an HTTP request was generated from the browser to the server every 10 minutes.

The request doesn’t actually do anything, but it allows the application server to keep the session alive while the user fills out the survey. Of course, this type of script could be used for any web application that relies on sessions, and I’ve used similar scripts in the past in the Plumtree portal, where a lost session can also cause problems:

<script>
     var sessionInterval = 1000 * 60 *10; // milliseconds to minutes
       var sessionRefreshURL = "/frevvo/web/login";

       refreshFrevvoSession = function() {

              // make the request
              var xmlhttp;
              if (window.XMLHttpRequest)
                     xmlhttp=new XMLHttpRequest();  // IE7+, Firefox, Chrome, Opera, Safari
              else
                     xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  // code for IE6, IE5
              xmlhttp.open("GET",sessionRefreshURL+"?sessionRefresh="+new Date().getTime(),true);
              xmlhttp.send();

              // set the timer to run again
              setTimeout (refreshFrevvoSession, sessionInterval);
       }
       setTimeout (refreshFrevvoSession, sessionInterval); // set the initial timer
</script>

Running Plumtree Portal on IIS7 and Windows Server 2008

Wednesday, September 19th, 2012

The latest version of WebCenter Interaction (aka Neo, or 10gR4) officially added support for IIS7 and Windows Server 2008. But WCI 10gR3 – or (gasp!) Aqualogic User Interaction or Plumtree don’t since IIS 7 didn’t exist way back then. We’ve discussed how to get these older revisions working on 64-bit Windows, but many of you don’t have the luxury of upgrading Plumtree or have cancelled your support and maintenance contracts (and, if you haven’t, why not?) .

Still, time marches on, new application servers and operating systems are introduced, and your server team is antsy to get you to upgrade what you can. So, today’s post is about getting older versions of WCI working on IIS7 and Windows Server 2008. It’s – of course – not officially supported, but from my testing with WCI 10gR3 it seems to work OK. Your mileage may vary, and I can’t say I’ve actually supported a production environment running 10gR3 in this configuration yet, so proceed at your own risk.

The problem starts with the portal installer – you’re likely to see something like the following lines in your error logs:

“E:\bea\alui\installlogs\portalappserver_deployment.log”(51,13): [echo] ERROR: Web Site Default Web Site does not exist. Virtual directory cannot be created.
“E:\bea\alui\installlogs\WebCenter_Interaction_InstallLog.log”(38038,51): Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_config-setup.log for details.
ANT Post-install Check:
Status: FATAL ERROR
Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_config-setup.log for details.
ANT Post-install Check:
Status: FATAL ERROR
Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_setup-service.log for details.
e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_setup-service.log:
BUILD FAILED
E:\bea\alui\uninstall\ptportal\10.3.0\register\register-configuration-manager.xml:191: java.io.FileNotFoundException: E:\bea\alui\configmgr\2.0\bin\configmgr.url (The system cannot find the path specified)

Basically, this is telling you that the installer wasn’t able to deploy the web app to IIS7. But, it does copy all of the appropriate files, so they’re ready to be deployed manually. Read on for the steps to get started in getting your old portal working with the latest IIS Application Server… (more…)

Application Server Sessions

Saturday, September 15th, 2012

WebCenter Interaction 10gR3 included these lines in the release notes:

Security and SSO
• Session fixation vulnerability. (Issue #7824904)

But what does that mean? First, let’s take a look at how sessions work on the World Wide Interwebs. By their very nature, web browsers are “stateless”. This means the CLIENT (web browser) makes a request to the SERVER, gets its information (a web page or image, for example), and closes that connection. The next time it makes the request, the server has no context from the previous request. To get around this, Netscape is credited with inventing the session cookie, which basically works like this:

  1. Web browser makes request to server the first time.
  2. Server realizes no “session” exists, so it creates a “blob of memory” to reserve for that user. It then creates a “key” that it sends to the browser in the form of a cookie in its response.
  3. The next time the browser makes a request, it sends that cookie. The server reads it and maps the cookie to the “blob of memory” that can contain anything, such as the login information of the user, or that user’s shopping cart.
  4. After a period of time (usually 15 minutes), the server realizes it hasn’t heard from the client and clears that memory to conserve resources.

Generally that “key” that we mentioned above is known as the “session ID”, and it’s usually passed in a cookie. But because not all browsers support(ed) cookies, a workaround was to allow the cookie to be passed on the query string. The problem is, if I know that session ID, I don’t even have to log into the web site you’re accessing – I can just send your cookie to that web site, and it will map my request to that “blob of memory” on the server that belongs to you – complete with your shopping cart or access to whatever private portal resources you had access to.

This is a pretty vague oversimplification, and if you’re interested, Wikipedia has decent articles on sessions and session fixation. WCI 10gR3 took additional measures to counteract the problem. Because it’s not open-source, it’s not easy to determine exactly what their solution was, but it involves clearing a session key when the user navigates away from the portal.

The problem is: what if clearing the session isn’t expected behavior? I ran into this exact scenario with a client using AquaLogic User Interaction (ALUI) trying to upgrade to WebCenter Interaction 10gR3. They had a custom SSO solution that redirected the browser to a login page at another domain. The server would redirect the browser to the new URL and the user would login there. After login, the browser would redirect back, but the original session had been deleted.

Bottom line: for most Plumtree installations, the 10gR3 upgrade is more secure and feature-rich. But use caution when applying this patch when you’ve got a custom SSO solution in-place, and test well before go-live!

Clear the recycle bin for all users

Tuesday, September 11th, 2012

Here’s an interesting problem I’ve run into recently with a Plumtree / ALUI / WCI server (but, of course, applicable to any server or desktop). A portal server was running out of disk space, and using the Cool Tool WinDirStat, I saw that D:\Recycler\ – the hidden Recycle Bin folder – was sucking down a ton of disk space, but my Recycle Bin was empty.

I knew deleting files in Windows simply moved them to a hidden folder (\Recycler – one hidden folder per drive), but didn’t realize it maintained a separate deletion history for each user. Turns out, since a lot of Systems Administrators had accessed the system before me, their recycle bins were consuming space – but because the folder was hidden, I couldn’t clear those out through Windows Explorer.

The solution was a Google Search away, and I came across this article from LifeHacker: Force Windows Recycle Bins to Empty for Every User on a System. This command simply deletes that hidden folder, effectively purging everyone’s recycle bin and reclaiming the lost space:

rd /s c:\recycler

Remember to run it as Administrator, and you may find some unused space you never knew was available. And don’t worry about breaking the Recycle Bin – Windows automatically recreates the folder when it’s not present.