Re: 1.4 version of IRequestCycleListener?
Hi, there's no direct equivalent in 1.4. Your WebApplication#newRequestCycleProcessor() could provide a processor subclass, doing some extra stuff before delegating to the super implementation. But you're probably better off just using a custom servlet filter. Have fun Sven Am 01.08.2018 um 14:17 schrieb Entropy: In our Wicket 6 projects, we have a IRequestCycleListener that does some things we want to do for every request (primarily involving auditing and a few other nits). We also have a couple 1.4 apps that we haven't been given permission to upgrade, but we want to add this same auditing listener. Is there an equivalent to IRequestCycleListener in 1.4? I see IRequestListener, but it doesn't seem to have any events, and it's child listeners all seem more specific. I just want a bit of code to run before and after every request. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
1.4 version of IRequestCycleListener?
In our Wicket 6 projects, we have a IRequestCycleListener that does some things we want to do for every request (primarily involving auditing and a few other nits). We also have a couple 1.4 apps that we haven't been given permission to upgrade, but we want to add this same auditing listener. Is there an equivalent to IRequestCycleListener in 1.4? I see IRequestListener, but it doesn't seem to have any events, and it's child listeners all seem more specific. I just want a bit of code to run before and after every request. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Content Security Policy support
PRs are welcome :))) sources for the guide are located here: https://github.com/apache/wicket/tree/master/wicket-user-guide/src/main/asciidoc Ajax components requires 'unsafe-inline' 'unsafe-eval', not sure how this can be fixed :( On Wed, Aug 1, 2018 at 2:32 PM Major Péter wrote: > > Hi, > > In that case I would suggest default-src 'self' as a better starting > point. The problem remains though, if one uses Ajax and/or has > placeholder tags for invisible components, one must have at least: > Content-Security-Policy: script-src 'self' 'unsafe-inline' > 'unsafe-eval'; style-src 'self' 'unsafe-inline' > > I'd wonder whether the style="display:none" cases would be simpler to > deal with by whitelisting its hash rather than trying to come up with a > Wicket specific CSS resource only to define a class for that purpose... > > cheers, > Peter > > 01/08/2018 08:18 keltezéssel, Maxim Solodovnik írta: > > Hello Peter, > > > > I also believe the general rule should be: deny All then allow one-by-one > > but this is general principle, the guide describing some configuration > > you can start with :) > > On Mon, Jul 30, 2018 at 3:50 PM Major Péter wrote: > >> > >> Hi, > >> > >> thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8 > >> years, so I was still thinking that Confluence was the source of truth). > >> > >> Reading through the section I don't feel that the suggestion there is > >> appropriate: > >> * using default-src https: allows to do pretty much anything as long as > >> the resource being loaded is over HTTPS (and getting a cert for free is > >> a pretty easy thing to do). > >> * IMHO setting default-src to 'none' and then one-by-one whitelisting > >> all the resource types is a better approach as it is much more limiting > >> * By enabling https: resources only, the "unsafe-inline" and > >> "unsafe-eval" requirements for script-src are not covered, and hence > >> Wicket's AJAX components won't actually work (well the fallback impls > >> will). > >> * This also doesn't tackle the style-src unsafe-inline requirements. > >> > >> Do you want me to file a doc bug for this? > >> > >> Regards, > >> Peter > >> > >> 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta: > >>> Have you already read this part of the guide? > >>> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks > >>> On Mon, Jul 30, 2018 at 3:18 PM Major Péter wrote: > > Hi, > > I'm trying to write a new Wicket application, and I wanted to use CSP > for added security. It seems like that there are two main issues: > * Wicket's AJAX support is highly dependent on inline and eval'd > JavaScript code > * component visibility is controlled using inline styles > > Is WICKET-5406 going to get some traction anytime soon, or are there > known workarounds for the above issues (like a CSP friendly AJAX > implementation)? > > Alternatively, I was thinking of a couple of ways to overcome these > issues, like: > * trying to use one-off resource references (if possible?) for > individual requests, so that instead of eval'ing, the code could be just > simply loaded instead? > * have a way to generate and retrieve nonces for inline resources and > make sure that Wicket sets the CSP header on its own. > * update Wicket itself to use text/json script elements to load its > configuration and pass JSON objects only for AJAX responses, so that > they no longer need to be eval'd. > > Are these approaches any good? > > Thanks, > Peter > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > >>> > >>> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Content Security Policy support
Hi, In that case I would suggest default-src 'self' as a better starting point. The problem remains though, if one uses Ajax and/or has placeholder tags for invisible components, one must have at least: Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' I'd wonder whether the style="display:none" cases would be simpler to deal with by whitelisting its hash rather than trying to come up with a Wicket specific CSS resource only to define a class for that purpose... cheers, Peter 01/08/2018 08:18 keltezéssel, Maxim Solodovnik írta: Hello Peter, I also believe the general rule should be: deny All then allow one-by-one but this is general principle, the guide describing some configuration you can start with :) On Mon, Jul 30, 2018 at 3:50 PM Major Péter wrote: Hi, thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8 years, so I was still thinking that Confluence was the source of truth). Reading through the section I don't feel that the suggestion there is appropriate: * using default-src https: allows to do pretty much anything as long as the resource being loaded is over HTTPS (and getting a cert for free is a pretty easy thing to do). * IMHO setting default-src to 'none' and then one-by-one whitelisting all the resource types is a better approach as it is much more limiting * By enabling https: resources only, the "unsafe-inline" and "unsafe-eval" requirements for script-src are not covered, and hence Wicket's AJAX components won't actually work (well the fallback impls will). * This also doesn't tackle the style-src unsafe-inline requirements. Do you want me to file a doc bug for this? Regards, Peter 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta: Have you already read this part of the guide? https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks On Mon, Jul 30, 2018 at 3:18 PM Major Péter wrote: Hi, I'm trying to write a new Wicket application, and I wanted to use CSP for added security. It seems like that there are two main issues: * Wicket's AJAX support is highly dependent on inline and eval'd JavaScript code * component visibility is controlled using inline styles Is WICKET-5406 going to get some traction anytime soon, or are there known workarounds for the above issues (like a CSP friendly AJAX implementation)? Alternatively, I was thinking of a couple of ways to overcome these issues, like: * trying to use one-off resource references (if possible?) for individual requests, so that instead of eval'ing, the code could be just simply loaded instead? * have a way to generate and retrieve nonces for inline resources and make sure that Wicket sets the CSP header on its own. * update Wicket itself to use text/json script elements to load its configuration and pass JSON objects only for AJAX responses, so that they no longer need to be eval'd. Are these approaches any good? Thanks, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Content Security Policy support
Hello Peter, I also believe the general rule should be: deny All then allow one-by-one but this is general principle, the guide describing some configuration you can start with :) On Mon, Jul 30, 2018 at 3:50 PM Major Péter wrote: > > Hi, > > thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8 > years, so I was still thinking that Confluence was the source of truth). > > Reading through the section I don't feel that the suggestion there is > appropriate: > * using default-src https: allows to do pretty much anything as long as > the resource being loaded is over HTTPS (and getting a cert for free is > a pretty easy thing to do). > * IMHO setting default-src to 'none' and then one-by-one whitelisting > all the resource types is a better approach as it is much more limiting > * By enabling https: resources only, the "unsafe-inline" and > "unsafe-eval" requirements for script-src are not covered, and hence > Wicket's AJAX components won't actually work (well the fallback impls will). > * This also doesn't tackle the style-src unsafe-inline requirements. > > Do you want me to file a doc bug for this? > > Regards, > Peter > > 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta: > > Have you already read this part of the guide? > > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks > > On Mon, Jul 30, 2018 at 3:18 PM Major Péter wrote: > >> > >> Hi, > >> > >> I'm trying to write a new Wicket application, and I wanted to use CSP > >> for added security. It seems like that there are two main issues: > >> * Wicket's AJAX support is highly dependent on inline and eval'd > >> JavaScript code > >> * component visibility is controlled using inline styles > >> > >> Is WICKET-5406 going to get some traction anytime soon, or are there > >> known workarounds for the above issues (like a CSP friendly AJAX > >> implementation)? > >> > >> Alternatively, I was thinking of a couple of ways to overcome these > >> issues, like: > >> * trying to use one-off resource references (if possible?) for > >> individual requests, so that instead of eval'ing, the code could be just > >> simply loaded instead? > >> * have a way to generate and retrieve nonces for inline resources and > >> make sure that Wicket sets the CSP header on its own. > >> * update Wicket itself to use text/json script elements to load its > >> configuration and pass JSON objects only for AJAX responses, so that > >> they no longer need to be eval'd. > >> > >> Are these approaches any good? > >> > >> Thanks, > >> Peter > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
