<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter>
In the filter mapping section of the web.xml add the following.
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
Before I installed the above filter on the customer box (which *only*
serves the webapp for our product), I tested it on our own box. And
seeing no immediate problems, I didn't bother to pull it out of our box.
Then I discovered that another webapp sharing the Tomcat server on our
box, one that *by design* is placed in a frame, in a page residing on
another server, had stopped working. With the filter in place, it works
fine if you go directly to the page, but it fails if you go to the page
on the other server.
That raises two questions:
1. Is there something I can set in the above code, in order to allow
this webapp to appear in the aforementioned frame where it is supposed
to appear, but not if it's put in a frame on some other arbitrary page,
elsewhere?
2. Are there other side effects of the HTTP header security filter that
I should know about? It seems that on the aforementioned customer box,
something happened recently that seems to be keeping our webapp from
exporting M$ Excel files to the user. We don't think it's related (and
have reason to believe it isn't), but one never can tell, and it never
hurts to ask.
--
James H. H. Lampert
(As my freshman woodshop teacher in high school was fond of saying, "The
only dumb question is the one that doesn't get asked.")
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
