Thanks Łukasz
looks good to me. Provides the possibility to opt out on any given fine
grained use case while maintaing a general stricter approach.
Best regards
Markus
PS: looking right now into another strange phenomenon on a different
topic while testing. I will open a separate thread. I need to do some
more testing.
Am 01.09.22 um 08:19 schrieb Lukasz Lenart:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
