Content-Security-Policy and X-Frame-Options header config in http://antispam.csu.edu.au:32224/?dmVyPTEuMDAxJiY0YzA0ZThiMjA1NmJhYTkyNT01QzM3QjFEOV81NzM5OF84Nzk1XzEmJmZiNjI0N2U4ODdhYTNmZD0xMzMzJiZ1cmw9aWRwJTJFcHJvcGVydGllcw==
Brent Putman
putmanb at georgetown.edu
Thu Jan 10 21:27:10 EST 2019
On 1/10/19 5:33 PM, Cantor, Scott wrote:
> On 1/10/19, 5:28 PM, "users on behalf of Losen, Stephen C (scl)" <users-bounces at shibboleth.net on behalf of scl at virginia.edu> wrote:
>
>> In browser "developer" mode I definitely saw two X-Frame-Options headers and two Content-Security-Policy headers
>> coming from the IDP, so I guess "last header wins?"
I imagine which one wins is likely browser-dependent.
> I can't reproduce that, so I don't know what to tell you. If it's Tomcat, then I'd rule that out. It does not physically do that in the code, it's a map with one entry per header name and if you're not supplying your own map object there's no way you could get the code to send two just by setting properties.
I also could not reproduce. But obviously something somewhere somehow
is setting them.
It would be interesting for the OP to unset the props in idp.properties
entirely as discussed in the thread and then see whether both sets
disappear, or only "ours". And/or if you comment out again in
idp.properties to set the properties back to the defaults, do you now
get 2 sets that are identical, or just 1 set?
In the servlet API adding headers is additive, so just thinking that
perhaps either the servlet container or a front-end web server is
setting them (either automatically or by config), or possibly it's
something that has been customized/added to web.xml that's not "ours".
It would also be helpful to know what the servlet container and version is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190110/571a2b49/attachment.html>
More information about the users
mailing list