Webtop 6.8.2 Available

Among the chaos this week, the release of Webtop 6.8.2 was buried.  See Alvaro’s blog post.

Webtop support page on DECN.


Webtop ESA-2016-088

EMC has posted an ESA for Webtop: ESA-2016-088: EMC Documentum Webtop Unsafe Deserialization Vulnerability.  Here is the text of the ESA:

Documentum Webtop has a java deserialization code which may not validate if the input stream contains any malicious code. This code may be leveraged to exploit the system using malicious payloads with the help of the vulnerable versions of Apache libraries used in WebTop.

The following EMC Documentum Webtop release contains resolutions to these vulnerabilities:

  • EMC Documentum Webtop 6.8.1 P04 and later
  • EMC Documentum Webtop 6.8 P16 and later
  • EMC Documentum Capital Projects 1.9 P25 and later
  • EMC Documentum Capital Projects 1.10 P12 and later

EMC recommends all customers upgrade at the earliest opportunity. In addition, Documentum Engineering is working to validate a code fix for the following product families. This code fix will be available in upcoming maintenance releases:

  • EMC Documentum Administrator 7.2
  • EMC Documentum TaskSpace 6.7

This ESA will be updated as code fixes become available.

This is an interesting ESA in that the vulnerability seems to be with Apache libraries, not Webtop directly, and no resolution or corrective action is given.  Usually, EMC announces ESAs after the issues have been corrected in a patch.

Webtop 6.8.1 Available

In case you missed the announcement last week, Webtop v6.8.1 is available for download.  This minor update to Webtop mostly contains security and performance improvements, as well as new platform certifications.

The update contains 54 fixed issues (while 170 issues remain open).  At a quick glance, it appears that this is just a roll-up of Patches 01-08.  This update also includes several fixed issues for the Documentum Application Connector (DAC).  See the Release Notes for details.

Webtop Musings

I have another blog post over at Armedia.  This one wonders why EMC | Documentum decided not to update their workhorse web client with Web 2.0 technologies in favor of deprecating it and promoting D2 and xCP.  Give it a read and let me know your thoughts.  http://www.armedia.com/blog/2015/02/documentum-webtop-musings/

Webtop 6.8 is GA

Webtop 6.8 is now available, check the download site.  Note:  As of this writing, there are two Documentum Webtop links on the download site.  I found Webtop 6.8 in the lower of the two links, it is not with Webtop 6.5, 6.6 and 6.7 versions.  UPDATE:  This has been corrected.  Webtop 6.8 is now found under the ‘Documentum Webtop’ link, all previous supported versions are found under the ‘Document Webtop Version 6.7 & Below’ link.

Webtop 6.8 is the long awaited version (here too) which contains changes to email management and security, adds support for Microsoft Office 64-bit and new browsers, and extends the effective life of Webtop to 2021.    However, there are some compatibility issues with retention policy services (RPS) and records manager (RM), according to the release notes. These will be addressed with patches to RM, RPS, and PRS in January 2015.

From the release notes:

With the changed email management features in Webtop 6.8, products in the Records Suite family (Records Manager (RM), Retention Policy Services (RPS), and Physical Records Services (PRS)) are not interoperable with Webtop 6.8. For updated information, refer to the knowledge base article, 195164.

From the KB article:

Customers running any version of Retention Policy Services (RPS) should not upgrade to Webtop 6.8 as there are known interoperability issues between Webtop 6.8 and RPS. These known issues are targeted to be fixed in the January 2015 Patch release of RPS 6.7 SP3.

RPS customers currently running 6.7 SP3 must wait until the availability of the January 2015 RPS 6.7 SP3 Patch. Upon patch availability customers may deploy that patch update and then upgrade from their existing versions of Webtop to Webtop 6.8.

RPS customers running versions prior to 6.7 SP3 must upgrade to RPS 6.7 SP3 first, then apply the January 2015 RPS patch and then upgrade from their existing versions of Webtop to Webtop 6.8.

Customers running Physical Records Services (PRS) along with Retention Policy Services (RPS), must wait for the January 2015 RPS 6.7 SP3 Patch to be available to ensure interoperability.

Customers running PRS along with Records Manager (RM), must necessarily wait for the Records “Frankly” release targeted for availability in Q3-2015 to ensure interoperability.

UPDATE:  The “Documentum Blog” announcement.

Embedding Webtop Advanced Search in an iFrame

A recent client uses a custom web application as a front-end to a mashup of several applications including a database, email, and Documentum. They wanted an easy way to search the content in Documentum, so we installed xPlore.  We were then faced with what UI to use.  As a start, we thought we would simply embed Webtop’s Advanced Search screen in an iFrame in the front-end application. That seemed reasonable, and turned out to be a fairly good solution.  However, getting there took some work.

Ticketed login URL

First of all, we had to figure out how to call the Webtop Advanced Search component from a URL. This wasn’t too tough, the Documentum Web Development Kit Development Guide  discusses this and how to use tickets to seamlessly login as a named user. We soon discovered that the order of the parameters passed on the URL was important, and that the Documentum Web Development Kit Development Guide had it wrong: the user’s ticket must be the last parameter passed.

A correctly formatted URL looks like this:

https://&lt;hostname>:<port>/webtop/component/advsearchcontainer?component=advsearch&docbase=docbase>& username=<username>&ticket=DM_TICKET%3dT0J...

(Thanks to Ryan Chadwick for figuring this out.)

So, to redirect the iFrame content to this URL, we simply added this to the iFrame definition:


Where <%=link%> is the URL specified above. (A lot of JSP and Java was used to acquire the individual components of the URL, like the user’s name and login ticket. The acquisition of these components is way beyond the scope of this post.)

Surprisingly, this simple solution worked for the Adanced Search component. However, it wouldn’t display any results because of the following error:

Message: Access is denied.
Line: 1736
Char: 1
Code: 0
URI: https://<host&gt;:<port>/webtop/wdk/include/datagrid.js

This amounted to some kind of cross-domain scripting error. Solving this problem proved to be a little more difficult.


Using the built-in Internet Explorer Developer Tools (F12), we were able to pin-point the source of the problem.  It is important to note that we were using Webtop 6.5 SP3 P21. The code and line numbers discussed below may vary a bit if you are using a different release.

On or about line 1732 begins the following if block:

if (!isGridHeightSpecified(contElem))

On line 1736 this script tries to access a window.frameElement that doesn’t exist (because we are not running in a full Webtop context). To remedy this situation, we copied the /webtop/wdk/include/datagrid.js file to /webtop/custom/include/datagrid.js and made the following changes to the code block at line 1732.

if (!isGridHeightSpecified(contElem))
// if in a frameset
var inFrame = false;
inFrame = (window.frameElement && window.frameElement.scrolling == "yes");
} catch (ex) {
// If we hit an exception, likely we're in a x-domain iFrame, but we still want to proceed...
inFrame = true;
//if (window.frameElement && window.frameElement.scrolling == "yes")
if (inFrame)
if (g_clientInfo.isBrowser(ClientInfo.MOZILLA))
// This will fail if we're in a x-domain iFrame, but only on Mozilla...
// Save original scrolling value which is going to be used on restore
window.frameElement._originalScrolling = window.frameElement.scrolling;
window.frameElement.scrolling = "no";
document.body.style.overflow = "hidden";
document.body.style.overflow = "hidden";

(Thanks to Mark Jeweler for figuring this out.)

Unfortunately, Webtop doesn’t have a customization mechanism for /wdk/include/*.js files. So even though this code fixed the problem, and we moved the file to the /custom directory, Webtop did not use it, and the error persisted.

URL rewriting

Step three of this process involved implementing a little URL rewriting in Tomcat. The idea was that anytime the server thought it was going to server /webtop/wdk/include/datagrid.js, rewrite the path so it served /webtop/custom/include/datagrid.js instead.  To accomplish this feat, we used the Tuckey UrlRewriteFilter (http://tuckey.org/urlrewrite/). See the website for installation and configuration details.  The most significant configuration we made for this filter was the rewrite rule in the urlrewrite.xml file. This is the rule:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite
PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
<rule enabled="true">
<note>redirect for datagrid.js problem</note>
<from casesensitive="false">/wdk/include/datagrid.js</from>
<to type="redirect">/webtop/custom/include/datagrid.js</to>

(Thanks to maheshg for this suggestion and help. See EDN discusion, https://community.emc.com/message/657942)


Users can now seamlessly search content directly from the front-end application without knowing they are leveraging Webtop to do it.  Too bad it took rewriting some core Webtop code and the introduction of URL rewriting to make it happen.

I have previously stated that I am not a Webtop guy, so perhaps there is a better solution than this. If you have one, I’d love to hear about it. That said, based upon the EDN discussion cited above, it seems like this is perhaps the best solution.  Is this easier/different in Webtop 6.6, 6.7, 7.0?

%d bloggers like this: