Trying to embed Clarity Portlets in Java web application page and getting error
Load denied by X-Frame-Options: http://Clarity.com/niku/nu#action:homeActionId does not permit cross-origin framing.
Need help to fix this config issue.
The message appears due to the following header being set in the responses by Clarity:
It is a 'hard coded' header, so the only way to configure around it would be things like either proxy the accesses to Clarity (using a 3rd party product) and have that proxy remove this header from the response, or something else that would probably be unsupported such as inserting some kind of a filter into Tomcat at a level that can intercept and control the response headers. As a personal test that wouldn't require any server changes, you can use a tool like Fiddler to act as a proxy and have it strip the header from the responses for your own workstation only.
The Use Filters checkbox needs to be enabled within it:
And then you can set to either delete the header entirely, or alter it to one of the other permitted values that may be better (but use one or the other lines/boxes, don't use both at once for the same header):
The latter option of programming a Tomcat filter is only a 'maybe' and probably requires enough coding knowledge in that area to have meant not needing to ask the question to begin with. The former option can be tested using Fiddler to make sure it will work, but then will require the implementation of a proxy server if not already in use that is correctly configured to pass through all the correct requests, whilst also stripping from the responses the headers that are not desired. Both of these options necessitate your Clarity instances being on premise and not On Demand. Both of these options may 'undo' the security restrictions that help to protect your system from being abused/hacked, so change those options under caution only.
When you say "hard-coded", is it at Tomcat level or Clarity level ? I'm trying to delete the header by changing the configuration file .setup/scripts/j2ee/tomcat/deploy.xml. See post Clarity Response Header and Frames . The changes are effective in tomcat-app-deploy/conf/web.xml after service restart.
I've made it work at the first load of Firefox / Chrome : the parameter X-Frame-Options was not present in the http header anymore. But then, at the first refresh of the page, the parameter appears again...
At this time, I've not managed to determine if it is a cache issue or a Tomcat / Clarity issue. I've been trying to switch between standard classes org.apache.catalina.filters.HttpHeaderSecurityFilter and custom com.niku.union.web.filter.ResponseHeaders, but so far, no luck...
I don't know that it will be a supported option as it's still not (to my knowledge) documented.
It was put in as a hard-coded in the Clarity side and done for security/vulnerability reasons to help block clickjacking attacks.
However product support have, conditionally and with heavy disclaimers, provided the following advice before that you might try:
1. Stop the app services.
2. Edit the properties.xml file.
3. In the webServerInstance element (for the app services, probably not the nsa/CSA one) add the following attribute and set it to false: useXframeOptions="false"
4. Save the properties.xml file.
5. Redeploy and start the app services.
Hope that helps. I'm no longer with CA myself, so if it doesn't work you may need to reach out to them for further assistance on it.
I see in that thread that you've tried the option and it isn't working for you anymore, but I'm fairly certain the option still exists so you could have a product version specific issue, or something else about its setup you need to address provided that the instructions were carried out as above - that will be why you'd need to probably engage CA support on it further.
Thank you very much for your time
Eventually, after several tests, I could make it work. It was not a cache or a web client issue.
The trick was to do both operations :
1/ Change the file deploy.xml to remove the hard-coded value SAMEORIGIN on parameter X-Frame-Option (Tomcat level)
2/ Change properties.xml to add the parameter useXframeOptions="false" on each webInstanceServer node; you need to it on all nodes, even the csa web service (Clarity level)
The operation 2 is effective immediately, whereas operation 1 needs a service restart.
I do not really understand why the feature was implemented at 2 different places (just to be sure I guess ?).
Hope that helps.
PS : For the new UI, you need to modify the tomcat file $NIKU_HOME/cappm/WEB-INF/web.xml
I think the main take away is that this isn't documented or a feature in the CSA or easily disabled only because it wasn't ever meant to be; the intent is for these to be enabled all the time. If and when it is to be a feature to be toggled on/off it would then be made available more simply.
Even if you get by X-FRAME-OPTIONS header the only thing you are going to see is the login screen. You will need a session for any real display.
If the portlets that you are interested in have a NSQL query data source, it isn't to hard to just pull the data into your java application and bind it to some UI component. For example, we have network technology refresh project which every location is a major milestone in the schedule. We have a NSQL query that provides each location status (red, yellow, green along with status comments). This is merged with location data (Lat / Lon) for the sites which is then fed into a Google map for display.
We pop it into a PPM html portlet but it could have been hosted in another web app.
Retrieving data ...