Junit4 Dependencies of WicketTester
Hello everyone, i wanted to ask if there is a possibility that the Junit4 Dependencies in WicketTester can be removed (i would provide PR if you like). Using Junit5 breaks these dependencies since Junit decided to break with their old API completely in version 5. Greetings, Johannes Renoth - 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, 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
Re: Content Security Policy support
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 > -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Content Security Policy support
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
