Re: CSP and UI libraries
Sorry for bringing such news :( On Fri, 28 Feb 2020 at 10:05, Sebastien Briquet wrote: > > Thank you very much for letting me know! > I didn't exactly know what to expect until I would put my hands in it, but > now I'm a little bit worried, haha ! > > Best regards, > Sebastien -- WBR Maxim aka solomax
Re: CSP and UI libraries
Thank you very much for letting me know! I didn't exactly know what to expect until I would put my hands in it, but now I'm a little bit worried, haha ! Best regards, Sebastien
Re: CSP and UI libraries
Hello Sebastien, Unfortunately this task might be challenging :( Kendo will not work in strict CSP mode :( https://docs.telerik.com/kendo-ui/troubleshoot/content-security-policy Other places to look at (should be easy to correct): DisplayNoneBehavior MessageDialog :))) On Thu, 27 Feb 2020 at 20:00, Sebastien Briquet wrote: > > Hi Martin, > > Actually that's a good point! I will try to upgrade Wicket jQuery UI to > wicket 9/CSP to see how it behaves... > > Thanks and best regards, > Sebastien -- WBR Maxim aka solomax
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi Andrew,
I thought of this solution as well and it will work. The major
advantage is that the styling is only added when it is actually used.
But it requires significantly more work to build and is a lot more
complex than the current solution. For this, we need some place to
accumulate element styling, like we do for JS event handlers. This
then needs to be rendered in the response.
The most complex part is ajax updates. These might change some of the
styling. Simply replacing the style element will not work, because in
an ajax request only the added components are rendered. Rendering a
style element per component will work, but is far from ideal. This is
why I went for the easy solution.
Emond
On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev wrote:
>
> Just as a brainstorm. Not sure if it's a good idea.
>
> Wicket potentially can add nounced style to the document with hidden
> elements hidden by id.
>
> Imagine generated HTML has components like these
>
> class="wupb-border"> class="wupb-foreground">
>
>
>
> #ida and #id9 must be hidden, so in the page header we add something like
> this
>
>
> #ida, #id9 {display: none;}
>
>
> Even if the wupb-progressBar has display: flex, the #ida will win. Will
> win even over #id8 .wupb-progressBar {display: fles}
>
> !important can potentially be added.
>
>
> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro >:
>
> > Hi,
> >
> > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene
> > wrote:
> >
> > > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Right now I have no enough knowledge to vote in this feature. One
> > thing I
> > > > didn't like, and I already mentioned it before, is some of us were
> > > waiting
> > > > for 9.x to be released some time ago (at least a few months ago I was
> > > > preparing some branch of our application and ported it to 9.x, after
> > > asking
> > > > about release plans) and all of the sudden this feature is introduced
> > and
> > > > all sub-frameworks depending on Wicket will have to be adapted.
> > >
> > >
> > > In which way sub-frameworks should be affected? I mean, as far as I
> > > understand it, if we disable CSP blocking configuration everything should
> > > work "the old way", and that's why I would prefer to keep CSP disabled by
> > > default.
> > >
> >
> > Well if something is supported at core level then if associated projects
> > want to comply with this new feature, which might be ideal, then they will
> > have to be adapted (or not?). I'm not talking about not releasing the new
> > feature. I'm talking about not releasing as part of 9.x, as it was said to
> > be almost ready for release a few months ago, and deffer it to 10.x (and
> > try to release it soon).
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
Re: WICKET-6725 styling of hidden elements: no vote yet
Just as a brainstorm. Not sure if it's a good idea.
Wicket potentially can add nounced style to the document with hidden
elements hidden by id.
Imagine generated HTML has components like these
#ida and #id9 must be hidden, so in the page header we add something like
this
#ida, #id9 {display: none;}
Even if the wupb-progressBar has display: flex, the #ida will win. Will
win even over #id8 .wupb-progressBar {display: fles}
!important can potentially be added.
чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro :
> Hi,
>
> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene
> wrote:
>
> > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Right now I have no enough knowledge to vote in this feature. One
> thing I
> > > didn't like, and I already mentioned it before, is some of us were
> > waiting
> > > for 9.x to be released some time ago (at least a few months ago I was
> > > preparing some branch of our application and ported it to 9.x, after
> > asking
> > > about release plans) and all of the sudden this feature is introduced
> and
> > > all sub-frameworks depending on Wicket will have to be adapted.
> >
> >
> > In which way sub-frameworks should be affected? I mean, as far as I
> > understand it, if we disable CSP blocking configuration everything should
> > work "the old way", and that's why I would prefer to keep CSP disabled by
> > default.
> >
>
> Well if something is supported at core level then if associated projects
> want to comply with this new feature, which might be ideal, then they will
> have to be adapted (or not?). I'm not talking about not releasing the new
> feature. I'm talking about not releasing as part of 9.x, as it was said to
> be almost ready for release a few months ago, and deffer it to 10.x (and
> try to release it soon).
>
> --
> Regards - Ernesto Reinaldo Barreiro
>
Re: WICKET-6725 styling of hidden elements: no vote yet
On Thu, Feb 27, 2020 at 11:56 AM Ernesto Reinaldo Barreiro wrote: > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > > In which way sub-frameworks should be affected? I mean, as far as I > > understand it, if we disable CSP blocking configuration everything should > > work "the old way", and that's why I would prefer to keep CSP disabled by > > default. > > > > Well if something is supported at core level then if associated projects > want to comply with this new feature, which might be ideal, then they will > have to be adapted (or not?). I'm not talking about not releasing the new > feature. I'm talking about not releasing as part of 9.x, as it was said to > be almost ready for release a few months ago, and deffer it to 10.x (and > try to release it soon). As I've explained in the other thread, it is very likely that not much needs to be done in additional frameworks. Also, when a framework is not yet compliant with CSP, the user can temporarily disable CSP or switch to a less strict version. As explained in the user guide, this is just one line of code. The changes made to the core of Wicket (removing inline styling and js) were absolutely necessary to be able to support a strict CSP via Wicket or any other way. This clearly is a wish of our users (and a personal wish as well, because our application also needs it). Also I think this is truly is a very unique feature. I don't think any framework offers such a strict CSP out of the box with so less effort from the user. Best regards, Emond
Re: CSP and UI libraries
Yes, All my prs were made with strict csp enabled Additional minor change is required to make tests pass Will create pr right after release On Thu, Feb 27, 2020, 20:32 Martin Grigorov wrote: > Thanks, Emond! > > @Maxim: since you started using Wicket 9.x Bootstrap 4.x recently: do you > use it with CSP enabled ? > > On Thu, Feb 27, 2020 at 3:17 PM Emond Papegaaij > > wrote: > > > Hi Martin and Sebastien, > > > > I see no need for checking if CSP is enabled or not. It is not hard to > > write your code to comply to even the strictest CSP. If it works with > > the strict CSP, it will also work when CSP is disabled or with a less > > strict CSP. Simply follow the few rules explained in the user guide. > > Note that if your library needs to check if a nonce is required, this > > is already supported, see > > ContentSecurityPolicyEnforcer.isNonceEnabled(). > > > > Our application uses WiQuery and several other frameworks, and I only > > had to make minor changes to make this application fully compliant > > with the strict CSP. No changes were required to WiQuery. A small > > change is required to the ChartJS library we use > > (https://github.com/haster/java-chartjs) because ChartJS tries to > > insert a stylesheet into the head. This stylesheet has to be rendered > > via Wicket to get the nonce. > > > > Best regards, > > Emond > > > > On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet > > wrote: > > > > > > Hi Martin, > > > > > > Actually that's a good point! I will try to upgrade Wicket jQuery UI to > > > wicket 9/CSP to see how it behaves... > > > > > > Thanks and best regards, > > > Sebastien > > >
Re: CSP and UI libraries
Thanks, Emond! @Maxim: since you started using Wicket 9.x Bootstrap 4.x recently: do you use it with CSP enabled ? On Thu, Feb 27, 2020 at 3:17 PM Emond Papegaaij wrote: > Hi Martin and Sebastien, > > I see no need for checking if CSP is enabled or not. It is not hard to > write your code to comply to even the strictest CSP. If it works with > the strict CSP, it will also work when CSP is disabled or with a less > strict CSP. Simply follow the few rules explained in the user guide. > Note that if your library needs to check if a nonce is required, this > is already supported, see > ContentSecurityPolicyEnforcer.isNonceEnabled(). > > Our application uses WiQuery and several other frameworks, and I only > had to make minor changes to make this application fully compliant > with the strict CSP. No changes were required to WiQuery. A small > change is required to the ChartJS library we use > (https://github.com/haster/java-chartjs) because ChartJS tries to > insert a stylesheet into the head. This stylesheet has to be rendered > via Wicket to get the nonce. > > Best regards, > Emond > > On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet > wrote: > > > > Hi Martin, > > > > Actually that's a good point! I will try to upgrade Wicket jQuery UI to > > wicket 9/CSP to see how it behaves... > > > > Thanks and best regards, > > Sebastien >
Re: CSP and UI libraries
Hi Martin and Sebastien, I see no need for checking if CSP is enabled or not. It is not hard to write your code to comply to even the strictest CSP. If it works with the strict CSP, it will also work when CSP is disabled or with a less strict CSP. Simply follow the few rules explained in the user guide. Note that if your library needs to check if a nonce is required, this is already supported, see ContentSecurityPolicyEnforcer.isNonceEnabled(). Our application uses WiQuery and several other frameworks, and I only had to make minor changes to make this application fully compliant with the strict CSP. No changes were required to WiQuery. A small change is required to the ChartJS library we use (https://github.com/haster/java-chartjs) because ChartJS tries to insert a stylesheet into the head. This stylesheet has to be rendered via Wicket to get the nonce. Best regards, Emond On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet wrote: > > Hi Martin, > > Actually that's a good point! I will try to upgrade Wicket jQuery UI to > wicket 9/CSP to see how it behaves... > > Thanks and best regards, > Sebastien
Re: CSP and UI libraries
Hi Martin, Actually that's a good point! I will try to upgrade Wicket jQuery UI to wicket 9/CSP to see how it behaves... Thanks and best regards, Sebastien
CSP and UI libraries
Hi, I'm creating a new thread to not hijack the discussion about the CSS utilities. On Thu, Feb 27, 2020 at 12:56 PM Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > Hi, > > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > wrote: > > > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro < > > reier...@gmail.com> wrote: > > > > > Hi, > > > > > > Right now I have no enough knowledge to vote in this feature. One > thing I > > > didn't like, and I already mentioned it before, is some of us were > > waiting > > > for 9.x to be released some time ago (at least a few months ago I was > > > preparing some branch of our application and ported it to 9.x, after > > asking > > > about release plans) and all of the sudden this feature is introduced > and > > > all sub-frameworks depending on Wicket will have to be adapted. > > > > > > In which way sub-frameworks should be affected? I mean, as far as I > > understand it, if we disable CSP blocking configuration everything should > > work "the old way", and that's why I would prefer to keep CSP disabled by > > default. > > > > Well if something is supported at core level then if associated projects > want to comply with this new feature, which might be ideal, then they will > have to be adapted (or not?). I'm not talking about not releasing the new > feature. I'm talking about not releasing as part of 9.x, as it was said to > be almost ready for release a few months ago, and deffer it to 10.x (and > try to release it soon). > I wanted to ask here whether we need an API that says whether CSP is enabled or disabled. For example UI libraries like Wicket Bootstrap & Wicket JQuery UI (and any other) may use it to decide how to behave depending on the result. Because at the moment there is no place for assumption - every library should be updated to assume that CSP is always enabled. > > -- > Regards - Ernesto Reinaldo Barreiro >
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi, On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene wrote: > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro < > reier...@gmail.com> wrote: > > > Hi, > > > > Right now I have no enough knowledge to vote in this feature. One thing I > > didn't like, and I already mentioned it before, is some of us were > waiting > > for 9.x to be released some time ago (at least a few months ago I was > > preparing some branch of our application and ported it to 9.x, after > asking > > about release plans) and all of the sudden this feature is introduced and > > all sub-frameworks depending on Wicket will have to be adapted. > > > In which way sub-frameworks should be affected? I mean, as far as I > understand it, if we disable CSP blocking configuration everything should > work "the old way", and that's why I would prefer to keep CSP disabled by > default. > Well if something is supported at core level then if associated projects want to comply with this new feature, which might be ideal, then they will have to be adapted (or not?). I'm not talking about not releasing the new feature. I'm talking about not releasing as part of 9.x, as it was said to be almost ready for release a few months ago, and deffer it to 10.x (and try to release it soon). -- Regards - Ernesto Reinaldo Barreiro
Re: WICKET-6725 styling of hidden elements: no vote yet
On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > Hi, > > Right now I have no enough knowledge to vote in this feature. One thing I > didn't like, and I already mentioned it before, is some of us were waiting > for 9.x to be released some time ago (at least a few months ago I was > preparing some branch of our application and ported it to 9.x, after asking > about release plans) and all of the sudden this feature is introduced and > all sub-frameworks depending on Wicket will have to be adapted. In which way sub-frameworks should be affected? I mean, as far as I understand it, if we disable CSP blocking configuration everything should work "the old way", and that's why I would prefer to keep CSP disabled by default. > Thus in practice the release of 9.x. by itself, with new CSS feature, will > not > bring any immediate value to many users as this will break most existing > applications. > > On Wed, Feb 26, 2020 at 10:34 AM Maxim Solodovnik > wrote: > > > [+] leave as is with .wicket--hidden & wicket-core.css > > > > IMO we should sheep the version which will work as expected > out-of-the-box > > According to my tests `hidden` attribute doesn't work (even `display: > > flex` breaks it) > > > > On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene > > wrote: > > > > > > +1 to vote. I find your concerns legitimate > > > > > > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > > > > > > > Hi all, > > > > > > > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > > > > > > > Due to the new CSP support we can no longer use inline styling to > hide > > > > elements. > > > > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > > > > > > > I don't think this is a good approach: > > > > > > > > - it adds a CSS file that is referenced by each page (after Wicket > > doing > > > > fine without it for 15 years) > > > > - the CSS is a mingle-mangle of out-of-date stylings (see > > > > .wicket--hidden-fields) > > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > > > - it introduces a new class naming scheme not used anywhere else > > (wicket--) > > > > > > > > IMHO we should remove that file again (and the required > infrastructure > > > > in ResourceSettings/WebApplication) and just > > > > use the HTML5 "hidden" attribute instead, whenever we want to hide > > > > something (Component, Form, ...). > > > > This "just works" in all browsers and is semantically correct. It has > > > > one caveat when an application's CSS changes the default styling of > > > > hidden elements (see > > > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but > > that's > > > > in the responsibility of the application developer. > > > > AjaxIndicatorAppender can just render a CSS class and leave the > styling > > > > to the application developer, nobody will be happy with the default > > > > "red" anyway. > > > > > > > > Thus I'll be starting a vote in the next days with the following two > > > > options: > > > > > > > > [] leave as is with .wicket--hidden & wicket-core.css > > > > > > > > [] use HTML5 "hidden" attribute instead > > > > > > > > This isn't the vote yet, it's just the announcement. > > > > Maybe others see a third (forth?) option or want to raise their > > concerns > > > > first. > > > > > > > > Sven > > > > > > > > > > > > > > > > > > -- > > > Andrea Del Bene. > > > Apache Wicket committer. > > > > > > > > -- > > WBR > > Maxim aka solomax > > > > > -- > Regards - Ernesto Reinaldo Barreiro > -- Andrea Del Bene. Apache Wicket committer.
