Like any other software package that moves along a release cycle, final tweaks were made to ADEP that can cause some inconsistencies for those of us that used a previous builds. In this case, I have found one of these inconsistencies while using the latest Adobe Enterprise Suite Extensions in Flash Builder 4.5.1 to create a Composite Application Framework (previously known as Mosaic) project.
When you create a Composite Application in Flash Builder, you will notice that a new folder called catalogs will be added to your workspace. This folder is a local “cache” of the Composite Application Framework catalogs that are stored in the ADEP experience server repository. When you install the experience server, you automatically get a default catalog aptly named default.cxml. Of course, you can create multiple catalogs for your Composite Applications – but that’s for another post.
If you have used previous prerelease builds of ADEP to create Composite Applications using Flash Builder, you will have this catalogs folder in your Flash Builder workspace. When you upgrade to a newer ADEP build, you need to delete this folder from your workspace before attempting to create a new Composite Application. One of these tweaks that has occurred between builds is that some tile definition attribute names have changed in the cxml file. Therefore, if you continue to use the old cxml format and try to deploy a new Composite Application, an error will be displayed in Flash Builder. The error will likely refer to the use of an invalid attribute called initialHeight – which has been changed to height.
Of course, deleting the catalogs folder means that existing Composite Applications you may have created in previous builds will no longer be registered in the repository. If you would like to keep your existing applications, then you would simply have to manually append your applications and tiles to the new default.cxml. Just be mindful to change the appropriate attributes like intialHeight to the new names. Don’t worry, the default.cxml has a commented block at the beginning that describes all of the attributes you may need.
Today, I installed the latest build of the Adobe Digital Enterprise Platform (ADEP) on one of my servers. I remotely administer this server – so once the installation was complete, the first thing I wanted to do is access the administration ui (adminui) using my browser to perform additional configurations. The URL is http:<fully_qualified_server_name>:8080/adminui. To my surprise, I received a denied access message when I attempted to log in. If I used the browser on the same server I just installed ADEP, it worked fine. I know what you are thinking… firewall blocking the port right? Nope. I have used this server for previous versions of LiveCycle ES and had opened port 8080 previously. Furthermore, if I used the server’s IP address, I could successfully access adminui. Now that’s a head scratcher! Let’s see what the application server log file has to say:
2011-08-05 12:32:08,898 WARNING [com.adobe.idp.um.auth.filter.CSRFFilter] (http-0.0.0.0-8080-1) Blocked request for resource:/adminui/login.faces due to invalid referer:http://<fully_qualified_server_name>:8080/adminui/login.faces. More information is available at http://www.adobe.com/go/learn_lc_hardening_10
What’s this CSRFFilter thing??? After a little digging I found out that in ADEP we have implemented a Cross Site Request Forgery (CSRF) defense filter. The ADEP CSRFFilter ensures that ADEP resources or URIs such as /adminui and /workspace can only be accessed through predefined referers (address of the source page requesting access to the resource). The goal is to prevent malicious requests riding piggy back on an authenticated browser session. During the installation process of ADEP, specifically in Configuration Manager, there is a system bootstrapping process that occurs. During this process, the ADEP document server determines the fully qualified host name of the server you are installing on and adds it (as well as IP address and localhost references) to the whitelist automatically. In ADEP, you can access the whitelist configuration page by logging into adminui and navigating to: Settings > User Management > Configuration > Configure Allowed Referer URL’s.
Why did it not work for me then? If the host name is automatically added to the whitelist, why was my request denied? The issue was actually cause by how the Windows machine name and domain configuration is set when I joined the corporate domain. The domain I joined was (I’ll leave out actual details to be sure the IT guys don’t hunt me down) ourdomain.xyz.org.com, which means that the fully qualified name is myserver.ourdomain.xyz.org.com which is what was automatically added to the whitelist during the bootstrap process. Here’s the rub… The way the network is setup at Adobe, that’s not the domain name we use in a URL to access our servers. The suffix we use is geo.org.com, so I would hit my server with http://myserver.geo.org.com:8080/adminui which of course is NOT in the whitelist. To correctly configure my ADEP server, I simply added that qualified server name to the whitelist and restart the application server. Yes, a restart of the application is required for the change to take effect. In case I forgot to mention it, remember to restart the application server :o). As I am sure you can tell, I did forget.
I doubt many people will run into this anomaly, but better be on the safe side.