Turning off rewriting of on* inline-js in Lift3

[Andreas Joseph Krogh]

Hi all.

 

We still have quite a lot of CSS matching the [onclick] selector, which doesn't play well with Lift3 new mechanisme of rewriting onclick-attributes to event-handlers (in LiftMerge.fixAttrs).

 

Is there a way to turn this off, that is, don't rewrite and use "pre-3 behavior"? If not, I propose to add a setting for it in LiftRules.

 

Thanks.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

[Antonio Salazar Cardozo]

There currently isn't. The feature is mostly meant to interact with ContentSecurityPolicy,

so I wouldn't necessarily be opposed to turning it off if the SecurityRules for JavaScript

allow inline JS. When I first wrote it SecurityRules wasn't ready yet, but now that SecurityRules

is in, we can properly play them off each other.

Obviously I also feel strongly that this is the framework nudging you in the direction of

developing “better” (and more securely), but I fully acknowledge that I have a strong and

biased opinion ;)

Thanks,

Antonio

[Andreas Joseph Krogh]

På fredag 24. april 2015 kl. 19:28:33, skrev Antonio Salazar Cardozo <savedf...@gmail.com>:

There currently isn't. The feature is mostly meant to interact with ContentSecurityPolicy,

so I wouldn't necessarily be opposed to turning it off if the SecurityRules for JavaScript

allow inline JS. When I first wrote it SecurityRules wasn't ready yet, but now that SecurityRules

is in, we can properly play them off each other.

 

Obviously I also feel strongly that this is the framework nudging you in the direction of

developing “better” (and more securely), but I fully acknowledge that I have a strong and

biased opinion ;)

Thanks,

Antonio

 

My point is mostly that we should offer a smooth migration-path from Lift < 3, where there probably exists lots of on* (especially onclick) in the code and CSS (having a CSS-rule [onclick] { cursor: pointer} is quite common I think). Rewriting that code to fit Lift3's current CSP is more than some work, and that may turn people away from Lift3.

[Antonio Salazar Cardozo]

We can do a couple of things, including relaxing the default Content-Security-Policy for the initial

Lift 3 release. Marking things that have been so transformed is a good idea, though (as per your

PR, which I'll make some comments on in Github).

Thanks,

Antonio