Documentum Thumbnail Server Security violation error

At some point on time, you might come across thumbnails not showing in your application and the following error on the Thumbnail Server log:

[DEBUG] : [DM_TS_T_RETRIEVE_DOCBASE_THUMB] Retrieving docbase thumbnail...
[DEBUG] : [DM_TS_T_RETRIEVE_STORE] Retrieving storage area...
[DEBUG] : getting storage area for docbase: xxxxxxxxx store: tcs_thumbnail_store_01
[DEBUG] : [DM_TS_T_CHECK_SECURITY] Checking security...
[DEBUG] : About to start reading files...
[DEBUG] : Trusted content store found, will use DFC for decryption
[DEBUG] : Content paramters are: format= null; page=null; page modifier=null
[DEBUG] : will be validating & retrieving object 09xxxxxxxxxxx
[DEBUG] : Session ok for xxxxxx
[ERROR] : Security violation: Url store details mismatches with objectID 09xxxxxxxxxxx

In this case you’ll probably will be wondering what’s going on. Well, this is basically a SCE (Severe Concept Error) coming from the talented team. Let’s check the faulty code coming from the getThumbnail servlet:

if (session != null) {
    IDfSysObject originalDoc = (IDfSysObject) session.getObject((IDfId) new DfId(objectId));

   String actualPath = originalDoc.getPathEx2(thumbFormat, thumbPage, thumbPageMod, false);
    int storeIndex = actualPath.indexOf(store);
    if (storeIndex != -1) {
        actualPath = actualPath.substring(storeIndex).replace("/", "\\");
        if (!actualPath.equalsIgnoreCase(store + "\\" + store)) {
            throw new IllegalAccessException();
    } else {
        throw new IllegalAccessException();

If you look closely you’ll realize the absurdity of this line: int storeIndex = actualPath.indexOf(store);

This clearly shows the lack of understanding about Documentum as:

  1. This creates a constraint between the filestore name, and the name of the folder on the disk
  2. Hi OT Engineering team, have you ever heard of something called dm_location object? If you already have the session, and you have the filestore, why don’t you get the folder location from the associated dm_location object instead?

So, until OT decides to fix this, if for some reason your folders on disk are not named exactly as your thumbnail stores, you already know why thumbnails might not show up.

OpenSAML authentication with Webtop 16.7.9

If you’re using SAML authentication with Webtop and you upgrade to 16.7.9 you’ll experience some issues (=it doesn’t work) if you need to sign the request to your IdP. Why is this happening?

In latest Webtop version Opentext has upgraded the bundled opensaml libraries from version 2 (released on 2011, support stopped on 2018) to version 4. In this many years that have passed since version 2 was released, the way the connection is done has been completely changed.

However, in this case OT engineering team properly updated the code that handles the request to the IdP. Unluckily, they didn’t do the same with the code that signs the request :/

Checking the code, you can see really weird castings between same types on the getServiceProviderSignature method:

       X509Certificate certificate = (X509Certificate)privateKeyEntry.getCertificate();
        BasicX509Credential credential = new BasicX509Credential();
        signature = (Signature)Configuration.getBuilderFactory().getBuilder(Signature.DEFAULT_ELEMENT_NAME).buildObject(Signature.DEFAULT_ELEMENT_NAME);

From this code, we can tell that OT was able to properly follow the instructions on how to send a request to the IdP ( but they were not so diligent with the signature process (, so what they basically did was “force the code to compile”.

Well, if you bother to follow the opensaml blog post containing the instructions on how to sign a request with OpenSAML 4 you’ll get something like this new fancy getServiceProviderSignature method:

//getServiceProviderSignature compatible OpenSAML 4
private Credential getServiceProviderSignature() {
    BasicX509Credential credentialx509=null;
    if (StringUtil.isEmptyOrNull(this.m_serviceProviderJKS) || StringUtil.isEmptyOrNull(this.m_serviceProviderJKSPwd) ||
        StringUtil.isEmptyOrNull(this.m_serviceProviderJKSKeyEntryPwd) || StringUtil.isEmptyOrNull(this.m_serviceProviderJKSKeyEntryAlias)) {
        traceMsg("Keystore proeprties are not configured properly for SAML request signing. So returning the signature as nullConfigure keystore properties if signing is enabled in Webtop and IDP configurations.");
        return null;
    try {
        KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
        FileInputStream fileInputStream = new FileInputStream(new File(this.m_serviceProviderJKS));
        char[] jksPassword = this.m_serviceProviderJKSPwd.toCharArray();
        char[] jksEntryKeyPassword = this.m_serviceProviderJKSKeyEntryPwd.toCharArray();
        keyStore.load(fileInputStream, jksPassword);

        KeyStore.PrivateKeyEntry privateKeyEntry = (KeyStore.PrivateKeyEntry)keyStore.getEntry(this.m_serviceProviderJKSKeyEntryAlias, new KeyStore.PasswordProtection(jksEntryKeyPassword));
        PrivateKey privateKey = privateKeyEntry.getPrivateKey();
        X509Certificate certificate = (X509Certificate)privateKeyEntry.getCertificate();
        credentialx509 = new BasicX509Credential(certificate, privateKey);

    } catch (Exception e) {
        Trace.println("Failed to get the signature to sign the SAML authentication request: " + e.getLocalizedMessage());
        throw new RuntimeException(e);
    return credentialx509;

which should work perfectly (there are some additional modifications to other methods, but this should get you going).

Opentext Documentum is coming next month

I didn’t realize that roadmap documents were updated last month. It looks like the February release is still going to happen (and I’ve been told a definite date, so it looks it won’t be delayed). After reviewing them (haven’t seen any changes :D), I can say:

  • Not much features regarding CS, the pattern/usage visualization and the s3 support (which, as far as I know, can be already done without official support) are the new features.
  • No word about DFS, and I know for a fact that several customers have actively asked for updates to current libs and extended support for application servers.
  • Clients get barely any changes (D2, Webtop, xCP).

I’m curious to see how many bugs are found in this first release from Opentext (and the brave customers that go first into the unknown :D), considering that some of the experienced Documentum staff left the company and the changes to the development cycle (that I guess happen when you move from a hardware company to a software company)

D2 configuration vs. Doclist widget

One weird requirement customer may want is to show different columns for different types. This kind of requirement is very difficult to meet with obsolete, difficult to customize and migrate webtop, because you’ll need to create a configuration such as:

<config version="1.0">
<scope type="custom_type">
<component id="objectlist" extends="objectlist:webtop/config/objectlist_component.xml">

and be done with it.

Now, how can we achieve this difficult customization in our beloved, configurable, easy to migrate D2? We can’t.

Stupid Useless Limited doclist widget will store a single column preference for the widget, meaning that if you want to apply certain column configuration, it will be applied for every location, no matter the type. Besides, the configuration is stored in the format object_type.attribute. This means that, if you have inherited attributes, you can easily find yourself in the following situations:

  • If you added subtype1.attribute, supertype and other subtypes won’t show any value, and it will only work for subtype1 objects.
  • If you have different labels for the same attribute in different subtypes, only the label for the object_type.attribute you added to the column will be shown (not much of a problem yet, as you won’t see any value).

As far as I know, this has been a feature request since D2 4.5 (released on April 2015), so after almost 3 years, this hasn’t been implemented yet. Even though I’m an optimistic person, and I’m sure (not really) that the “software company” will improve D2, we can, somehow, implement this (in a very rudimentary way, to be honest).

The current behaviour of the doclist widget is basically located in com.emc.d2fs.dctm.content.FolderContent. This class receives a request to retrieve and return the contents of a folder.

The two main methods that are interesting to our requirement would be getContent and getFilteredContent.

These methods receive some parameters, and they generate a query to retrieve objects from the folder, and then return a resulset (DocItems object) with the objects from the folder.

So, in case you want to “configure” the values shown (note that you can’t, or at least I haven’t been able to, change the columns shown in the widget, so data won’t match columns names), you’ll need to:

  • Modify listColNames List of String values with only the attributes you want to retrieve.
  • Take the List of Items returned by the ContentBuilder class and, for each attribute stored, customize the attribute name with the column you want to show the value in.
  • Replace OOTB FolderContent class with your own.

Of course, you have to have this in mind when migrating to a new D2 versions, because I’m quite sure this won’t work as expected in every D2 version…

Documentum 16.3 delayed until Feb 2018

If you access the new support page, there is a section where you can find roadmaps for the products, and if you check the Documentum related ones, you’ll see the target date for ths new version listing new features. Without going into much detail (As I’m not sure how public this info is), these caught my atention:

  1. Ongoing exposure of D2 APIs through REST (goodbye DFS?)
  2. Native support for S3 object storage protocols to alleviate storage costs (goodbye OnDemand, hello AWS?)
  3. New REST Services (see #1, no mention of DFS anywhere to be found)
  4. Webtop will get a 16.3 version (yeah!)


Webtop extension will stop working on Firefox 57

In November, Mozilla will release Firefox 57. This version will replace XUL with WebExtensions, this means every addon/extension not developed with the WebExtension API will stop working. The current extension for Webtop is not compatible with WebExtensions:


I wonder if OpenText will show us that they are a “software company” instead of the former Documentum owner which was a “hardware company” and have a new extension ready by the time Firefox 57 is released…

PS: I’m not even sure the extension will work on FF57, as Mozilla hasn’t implemented file access API due to security reasons, so I’m not sure if it’s even possible to port the extension to WebExtensions. (Maybe it is time for a HTML5 transfer mechanism?)

Why Migrate to Documentum D2

I’ve just seen this post by OpenText and I couldn’t resist to add some comments:

One of the striking advantages of a D2 application versus a Webtop application is that upgrades become much easier, and keeping up to date with product development and patches becomes so much easier, because D2 applications are constructed in the configuration framework, and upgrade of the D2 platform does not require ANY work on the configuration.

As long as your business requirements doesn’t force you to develop widgets/extensions/customization of core services. Then you’re in worst position than with other clients, because if Documentum documentation is usually lacking, you’ll be amazed with D2 documentation.

Customers choose their products based on complex weighted matrices of technical considerations, comparing functional details, platform characteristics and implementation approaches before establishing a platform standard within the organization for Enterprise Content Management (ECM).

If any customer would bother to do that, EMC would’ve hardly have sold any xCP 2.0/2.1/2.2 license.

These days, the goal is more likely to be user acceptance, or better put – user adoption –

The goal is selling licences.

By the way, D2 is a good fit (with its own flaws, as Webtop has) if customer sticks to configuration and doesn’t want anything else. Any other case needs to be carefully reviewed before making a decision.


Updated roadmap, webinar and FAQ from OpenText Documentum

If you registered for the webinar OpenText held a few weeks ago (if you didn’t, maybe you can check Andrey’s post on the subject), you should have received an invitation to some site from OT with a FAQ about the Documentum stack. I’m not going to paste it here, just in case it’s not public, but IMHO, the highlights are:

  • Content Server: Aligment with ECD. No new features but trying to move to a microservices architechture. It probably means CS won’t evolve anymore.
  • Webtop: Several points on this. Will keep being supported and updated to support latest CS.
  • Rest: Every new product based on this. No mention about DFS (I hope it’s dead, unless they decide to update with libraries from this decade)
  • xCP: It looks like xCP 1.x support will be over by the end of 2019.
  • Support: Still through EMC’s site until the end of the year.

Multiple environments with Tomcat/DA

Similar to the previous post about configuring dqMan/DQLTester (Multiple environments with dqMan/DQLTester), a Tomcat with DA can be configured the same way:

Folder structure:

  • da.bat
  • bin
  • conf
  • jre
  • lib
  • logs
  • webapps
  • properties
    • env1
      • dev
        • dmcl.ini
      • prod
        • dmcl.ini
    • env2
      • dev
        • dmcl.ini
      • prod
        • dmcl.ini
  • etc.


@Echo off
SET folderbase=dfcproperties

echo ****************
echo 1. env1 dev
echo 2. env2 prod
echo ****************

SET /p var= ^> Choose option: 

if "%var%"=="1" goto op1
if "%var%"=="2" goto op2

SET foldervar=%folderbase%\env1\dev
goto finish

SET foldervar=%folderbase%\env1\prod
goto finish

set JAVA_HOME=%cd%\jre
set\%foldervar%\ -Dfile.encoding=UTF-8 -Xms128m -Xmx512m -XX:+UseG1GC

start "" /D %cd%\bin /B %cd%\bin\catalina.bat start