Eliminate custom filter in favor of IdP's response header support
Description
Environment
Confluence content
Activity
Henri Mikkonen September 8, 2023 at 8:09 AM
Verified that the current implementation adds the Content-Security-Policy and X-Frame-Options to the user-facing views.
It corresponds to the behaviour that was previously achieved by setting property
Also removed the property from oidc.properties.
Scott Cantor August 2, 2023 at 2:23 PM
Docs TBD but I committed a change that I think should work fine. I didn’t leave any stub of the original behind. The legacy system properties are no longer needed but I doubt they were used too much outside of us needing it in the testbed because of how the registration worked.
With the new IdP, the servlets and filters are only registered dynamically with the latest web.xml so the testbed doesn’t register them in the other non-IdP contexts.
If somebody was really preventing the headers they themselves enable from applying to these paths, that would take some additional work but I would hope there’s no obvious need to do that in general or we shouldn’t be auto-applying the filter to those paths to begin with.
Needs to be tested obviously.
We should be able to collapse out the response header filter from the OP and just use the IdP’s filter. This is still a bit of work in progress but we should be able to allow for the necessary level of control given that under normal conditions the defaults should work fine.
The main thing that led to the OP filter was the inability to easily extend the set of paths the original filter would hit without changing web.xml. The IdP now uses the same kind of runtime approach the OP did, and it has an extensible way of adding path prefixes to guard.
The one hitch is control over this, but we can fix the IdP so that the condition guarding the filter is pluggable so that in the edge cases it could be overridden entirely.