How to configure white list for the new CSRF filter in ADEP


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 [] (http- 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

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), which means that the fully qualified name is 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, so I would hit my server with 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.

Comments Closed

7 Responses to How to configure white list for the new CSRF filter in ADEP

  1. meaman says:

    Good to know. Hopefully there aren’t too many more gotchas! Thanks for this.

  2. Gary Gilchrist says:

    Actually yes, I seen Girish Bedekar run into this problem on Thursday. It seemed that unless you were accessing the server from a browser on localhost then workspace would just kick you out the second you logged on (I am sure that was in the log too, had we looked!) I know about the CSRF filter but never correlated it to the Windows Domain set up. Great article, Marcel and nice find!

  3. Pingback: New in ADEP Document Services – CSRF Filter | The Adobe® Digital Enterprise Platform (ADEP) Blog (formerly LiveCycle Product Blog)

  4. asbestos says:

    Thank you!

  5. Sandro Looser says:

    Thanks to your blog I found the reason for a slightly different problem. On my localhost I tried to run an ADEP application with a guide containing an image field. But whenever I wanted to upload an image I got a similar error as you describe it – however in this case the problem is caused “due to a null referer”.
    Adding additional domains to the white list would not help in this case. After having a look at the CSRF Documentation, the only solution for my problem I could think of, was to empty the whitelist (and to reboot JBoss :-). As a result null referers are accepted – but of course it is not really improving the system’s security… So if anyone has an idea for a better solution for this particular problem I’d be interested.

  6. Dieter says:

    Ofcourse i run into the same, however i had actual the problem since i was not using any FQN to use directly a IP address which i receive on the server through a wireless router. Now of course this one changed form time to time so i tried to enter the whole class of IP addresses which did not work neither http://192.186.2:0 or https://192.168.2:0

    but what helped was the entry on the start script ….. If you don’t need protection against CSRF, you might stop the server, and restart it using JAVA argument in the startup script of the server.

    also deleting the whole whitelist would help and do the same 😉 for demo it is fine, for production of course nothing to recommend

  7. Diego Silva says:

    Great article! Saved my day 🙂