After re-thinking my idea with a dedicated stack, I prepared a PR which allows to disable those interceptors https://issues.apache.org/jira/browse/WW-5218
In other ways no one will adopt them, enforcing users to use them with the option to disable them should help raise more notions about CSP, wdyt? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ śr., 31 sie 2022 o 14:29 Johannes Geppert <jo...@apache.org> napisał(a): > > +1 for dedicated stack, but not sure if we should name it "default secure > stack" as it implies that the other stacks are not secure. 😉 > > My 2ct on this > > Best Regards > > Johannes > > i...@flyingfischer.ch <i...@flyingfischer.ch> schrieb am Mi., 31. Aug. > 2022, 14:20: > > > Creating a new default secure stack sounds good to me. Thank for > > considering. > > > > As far as I can see there would be 4 additional interceptors in this > > secure stack: > > > > CoepInterceptor.java > > CoopInterceptor.java > > CspInterceptor.java > > FetchMetadataInterceptor.java > > > > And the appropriate resources used by them: > > ResourceIsolationPolicy.java > > StrutsResourceIsolationPolicy.java > > > > Best regards > > Markus > > > > > > Am 31.08.22 um 14:11 schrieb Lukasz Lenart: > > > I think disabling them doesn't make sense - these are just > > > interceptors so you can create your own stack without them. I would > > > rather create a new default secure stack and move those interceptors > > > into that stack, wdyt? > > > > > > > > > Regards > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
