Re: Content Security Policy without unsafe-inline
In theory, the data URL approach sounds perfect. But in reality we'd be swapping this: scriptalert('hello');/script For this: script src=data:text/javascript;charset=utf-8,alert('hello'); / As you mentioned, it's likely that at least on browser won't support this (I'm looking at you IE!). As I said, I'm not sure it actually achieves anything in terms of security (apart from ticking a box).
Re: Content Security Policy without unsafe-inline
Ticking certainly, however my dreadful js tells me that whatever whacky functions I've made can be parameterised-in-a-template to be received by a t5 component. Extract their name (interface like) or some other more integrated language binding thing.. Linking them within tapestry and it sounds like mod_perl mod_php mod_jquery mod_app In the case of a calendar app using bootstrap and joda time, say an interface had inXDays() and the html day div highlights or pops up an edit bubble, and that edit bubble had the next+cool+mobile+version+of+a+js+gesture+framework, a la today's WYSIWYG widgets. Gesture or camera, with websockets in html5, those divs are gonna need some kind of policy applied in internetworking projects. Js abstraction sounds timely, will be interesting to see what can happen in html5 land. Bringing it back to the issue at hand, a t:Script src=alert(hello) / that could wrap the ugly bits at least. Java class stuff for managed/designed/schedulable script dev though... A dreamable maven task - although I'd do it in bash separately cos its quicker and simpler and delegatable and heaps more l33t :P Cheers Chris On 06/02/2014 9:21 pm, Lance Java lance.j...@googlemail.com wrote: In theory, the data URL approach sounds perfect. But in reality we'd be swapping this: scriptalert('hello');/script For this: script src=data:text/javascript;charset=utf-8,alert('hello'); / As you mentioned, it's likely that at least on browser won't support this (I'm looking at you IE!). As I said, I'm not sure it actually achieves anything in terms of security (apart from ticking a box).
Re: Content Security Policy without unsafe-inline
It's easy to say it should be cached until you realize that the application could be running in a cluster. At that point, you need to have that cached data available across all servers in the cluster ... that means you need to store it in the HttpSession, which is exactly the opposite approach that we should be headed to. What's annoying is that if Tapestry created some HTML5 elements for this purpose; say require and init; it would pass the CSP even though it would be exactly as hackable as having the inline script. Meanwhile, if there's a man in the middle, having an inline script is no different than having an external script in terms of injecting new client-side executable content into the page. This is a cost to Tapestry's flexibility that was not predicted years ago when the stack approach was created. For modern applications, there should be only a single stack, and there should be only a single page. But sometimes you play the cards you are dealt. On Wed, Feb 5, 2014 at 3:37 AM, Kristian Marinkovic kristian.marinko...@gmail.com wrote: looking at my migrated Tapestry 5.4-beta-2 app i can only see two inline scripts. The requirejs configuration (shim, ...) and the require call itself. Is it possible to move those into a dynamically generated js instead, that's included with a script tag? the requirejs config could by cached. And the require call would be page specific. Should we create a jira ticket? removing the javascriptsupport methods is not a good idea as it breaks backwards compatibility. on the other hand removing in 5.5 would be nice :) g, Kris On Tue, Feb 4, 2014 at 8:52 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). I don't know a politer way of saying this, but I already said that Tapestry 5.4 is already doing that at least twice. I'm having a really unlucky day. :( -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Content Security Policy without unsafe-inline
I agree; this is an ugly hack to satisfy the arbitrary CSP requirement. On Thu, Feb 6, 2014 at 5:20 AM, Lance Java lance.j...@googlemail.comwrote: In theory, the data URL approach sounds perfect. But in reality we'd be swapping this: scriptalert('hello');/script For this: script src=data:text/javascript;charset=utf-8,alert('hello'); / As you mentioned, it's likely that at least on browser won't support this (I'm looking at you IE!). As I said, I'm not sure it actually achieves anything in terms of security (apart from ticking a box). -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Content Security Policy without unsafe-inline
I agree the data url sounds interesting but is not really practical for a general purpose public site. I do think this might be interesting though t:script cachePolicy=never require=jquery t:id=hello alert(hello ${user}); \t:script That becomes something like: script src=.../page.hello:script:sha1ofcontent which returns: define([jquery], function(jquery) { alert(hello Barry); } This gives you simple dynamic javascript from a url that will work across a cluster. It would be easy to set the cache policy and might be possible to include in a stack if the script is static. The state would be managed just like an event link because it's really just an event link that returns Javascript instead of say a Zone. On Thu, Feb 6, 2014 at 4:20 AM, Lance Java lance.j...@googlemail.comwrote: In theory, the data URL approach sounds perfect. But in reality we'd be swapping this: scriptalert('hello');/script For this: script src=data:text/javascript;charset=utf-8,alert('hello'); / As you mentioned, it's likely that at least on browser won't support this (I'm looking at you IE!). As I said, I'm not sure it actually achieves anything in terms of security (apart from ticking a box).
Re: Content Security Policy without unsafe-inline
What's annoying is that if Tapestry created some HTML5 elements for this purpose; say require and init; it would pass the CSP even though it would be exactly as hackable as having the inline script. Meanwhile, if there's a man in the middle, having an inline script is no different than having an external script in terms of injecting new client-side executable content into the page. Howard, I don't think CSP is trying to prevent a man in the middle attack. It's trying to stop an XSS hack. Let's consider alert('hello'); Where 'hello' comes from a request parameter. A hacker could create a dodgy link on their site and force users to pass a parameter of hello');doSomethingEvil(); in a similar way to a SQL injection attack. I'm starting to like your idea of require and init. Please hear me out ;) What we want: Allow require, allow init, allow invocation of functions defined by our app What we want to prevent: A hacker injecting and executing arbitrary javascript If we came up with some custom set of tags, we could restrict what's allowed: eg: require module=myutils function=doStuff{foo:value1, bar:value2} /require init function=myInitializer{x:y}/init I'm not sure that I love it. But it does solve the problem.
Re: Content Security Policy without unsafe-inline
looking at my migrated Tapestry 5.4-beta-2 app i can only see two inline scripts. The requirejs configuration (shim, ...) and the require call itself. Is it possible to move those into a dynamically generated js instead, that's included with a script tag? the requirejs config could by cached. And the require call would be page specific. Should we create a jira ticket? removing the javascriptsupport methods is not a good idea as it breaks backwards compatibility. on the other hand removing in 5.5 would be nice :) g, Kris On Tue, Feb 4, 2014 at 8:52 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). I don't know a politer way of saying this, but I already said that Tapestry 5.4 is already doing that at least twice. I'm having a really unlucky day. :( -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Kristian, I'm still not sure you get the need for the inline script / JavaScriptSupport. Let's consider a Google map component with markers on it. With inline scripts, we can include the empty div and the markers in a single request. Without inline scripts you would need to either: 1. Include the markers in the markup somehow using data attributes or hidden html elements and then use a selector to populate the Google map with markers as it loads 2. Fire an AJAX request to get the markers. Option 1 can get a bit messy and option 2 has a delay. I don't think we need to deprecate javascriptsupport. I like having an option 3 :)
Re: Content Security Policy without unsafe-inline
i also think it's up to the development team to decide how they want to develop (inline-scripts vs. no inline-scripts). sometimes inline-scripts make things easier. having a choice is good anyways. still, do you think it is worth moving the requriejs specific inline-scripts into a dynamically generated js file? On Wed, Feb 5, 2014 at 9:49 AM, Lance Java lance.j...@googlemail.comwrote: Kristian, I'm still not sure you get the need for the inline script / JavaScriptSupport. Let's consider a Google map component with markers on it. With inline scripts, we can include the empty div and the markers in a single request. Without inline scripts you would need to either: 1. Include the markers in the markup somehow using data attributes or hidden html elements and then use a selector to populate the Google map with markers as it loads 2. Fire an AJAX request to get the markers. Option 1 can get a bit messy and option 2 has a delay. I don't think we need to deprecate javascriptsupport. I like having an option 3 :)
Re: Content Security Policy without unsafe-inline
Just to poke my uninformed and long-worked-days nose in, I reckon if a bit of sample code that did this caching (and may i chime in, and perhaps allowed for a tapestry configuration symbol to enable/disable this behaviour) were to magically be attached to a jira, then the likelihood of it being considered for 5.5 would sky rocket. Being somewhat interested in mitigating against breaches and having not given 5.4 a decent look at yet, read this comment (with its tired owners dry tone) with a grain of salt I'll just beg my pardon out of this politely and fix a drink :) If the stakeholders of a project wish this behaviour, and no gmaps stuff is ever likely to be needed, could be a nice feature. Cheers Chris On 05/02/2014 7:38 pm, Kristian Marinkovic kristian.marinko...@gmail.com wrote: looking at my migrated Tapestry 5.4-beta-2 app i can only see two inline scripts. The requirejs configuration (shim, ...) and the require call itself. Is it possible to move those into a dynamically generated js instead, that's included with a script tag? the requirejs config could by cached. And the require call would be page specific. Should we create a jira ticket? removing the javascriptsupport methods is not a good idea as it breaks backwards compatibility. on the other hand removing in 5.5 would be nice :) g, Kris On Tue, Feb 4, 2014 at 8:52 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). I don't know a politer way of saying this, but I already said that Tapestry 5.4 is already doing that at least twice. I'm having a really unlucky day. :( -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Chris, I was beginning to think along the same lines. A configuration symbol (boolean) to choose either an inline script or an extra (page specific) js import using the token + time to live strategy sounds like a good solution to me.
Re: Content Security Policy without unsafe-inline
If we were to use a token, care would need to be taken with token generation such that it's not predictable. We don't want hackers intercepting sensitive data meant for another client.
Re: Content Security Policy without unsafe-inline
On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic kristian.marinko...@gmail.com wrote: i also think it's up to the development team to decide how they want to develop (inline-scripts vs. no inline-scripts). sometimes inline-scripts make things easier. having a choice is good anyways. still, do you think it is worth moving the requriejs specific inline-scripts into a dynamically generated js file? I think we already discussed the options in this thread. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
does t5's form generation hmac stuff lend itself to this non predictable task? Digressing a bit, A log would show nuisances taking guesses. At the extreme scale of sensitive info and network architecture, the cat can be skinned at the network(ing layer). On 05/02/2014 10:06 pm, Lance Java lance.j...@googlemail.com wrote: If we were to use a token, care would need to be taken with token generation such that it's not predictable. We don't want hackers intercepting sensitive data meant for another client.
Re: Content Security Policy without unsafe-inline
I wrote a javascript cache for tapestry5-jquery a few years ago https://github.com/got5/tapestry5-jquery/tree/master/src/main/java/org/got5/tapestry5/jquery/services/js oddly enough I wrote it so you could use inline javascript in a tml file with zones. I believe I created a couple of implementations. One that stores javascript in the session and the other that uses a map and TTL. Personally I think it would be much easier if you could just put your javascript inside the tml files and have Tapestry handle the rest. It seems like there are too many files in too many places On Wed, Feb 5, 2014 at 5:38 AM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic kristian.marinko...@gmail.com wrote: i also think it's up to the development team to decide how they want to develop (inline-scripts vs. no inline-scripts). sometimes inline-scripts make things easier. having a choice is good anyways. still, do you think it is worth moving the requriejs specific inline-scripts into a dynamically generated js file? I think we already discussed the options in this thread. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Another consideration with the token approach is clustering. Either a sticky session or a distributed cache are required.
Re: Content Security Policy without unsafe-inline
Any thoughts on using a data uri? http://en.m.wikipedia.org/wiki/Data_URI_scheme On 5 Feb 2014 13:13, Lance Java lance.j...@googlemail.com wrote: Another consideration with the token approach is clustering. Either a sticky session or a distributed cache are required.
Re: Content Security Policy without unsafe-inline
On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java lance.j...@googlemail.com wrote: Any thoughts on using a data uri? Good catch, Lance. Supposing browsers support it, and I don't know the answer, it would be the ideal solution. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
But would we actually be solving anything? Or are we just ticking a box :) On 5 Feb 2014 13:34, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java lance.j...@googlemail.com wrote: Any thoughts on using a data uri? Good catch, Lance. Supposing browsers support it, and I don't know the answer, it would be the ideal solution. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
The reason I wrote the session cache was to support clustering. The data uri would solve that problem also. Before data attributes I found it useful because it made some things much simpler than the Tapestry 5.3 way of doing things. Since you can put scripts in the tml file you can use properties to populate the scripts so each script is customized to the user. Simple example in your tml file: script alert(hello ${user}); /script This would be converted to a script file with a url. If you could make it work like an event link that returned javascript from the page you don't even need the cache. I've though about implementing that but never started (this also solved the clustering problem and you don't need a cache). With Tapestry 5.3 things like this required a lot of code. 5.4 is better but still requires an extra javascript file. On Wed, Feb 5, 2014 at 7:37 AM, Lance Java lance.j...@googlemail.comwrote: But would we actually be solving anything? Or are we just ticking a box :) On 5 Feb 2014 13:34, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java lance.j...@googlemail.com wrote: Any thoughts on using a data uri? Good catch, Lance. Supposing browsers support it, and I don't know the answer, it would be the ideal solution. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Wed, 05 Feb 2014 11:37:36 -0200, Lance Java lance.j...@googlemail.com wrote: But would we actually be solving anything? Or are we just ticking a box :) :D Well, we would solve the original request and Tapestry would be able to tell it's optionally CSP-compliant out of the box. It would take a couple hours to get done (including a symbol defaulting to disabled), so I see no much of a downside to it. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
IMHO all javascript functions should be defined in static, cacheable js files. The inline scripts are just for passing dynamic arguments to functions defined in static scripts.
Re: Content Security Policy without unsafe-inline
Well, we would solve the original request and Tapestry would be able to tell it's optionally CSP-compliant out of the box I'm not sure that it would be CSP compliant since I'm sure there's an eval() in the js somewhere for ajax responses.
Re: Content Security Policy without unsafe-inline
The reason I wrote the session cache was to support clustering. I'm against the idea of forcing a session to support this.
Re: Content Security Policy without unsafe-inline
I would agree. I think the state should be in the URL. I also think it should be implemented like an event link with a zone response not a cache. That allows the developer to store the state just like any other event link. On Wednesday, February 5, 2014, Lance Java lance.j...@googlemail.com wrote: The reason I wrote the session cache was to support clustering. I'm against the idea of forcing a session to support this.
Re: Content Security Policy without unsafe-inline
I'm not suggesting the javascript request should be stateless. The lag between the two requests means the db can be in an inconsistent state between the two requests and the markup doesn't match the javascript. For this to work the js and markup need to be authored in the same request.
Re: Content Security Policy without unsafe-inline
On Wed, 05 Feb 2014 17:28:23 -0200, Lance Java lance.j...@googlemail.com wrote: I'm not suggesting the javascript request should be stateless. The lag between the two requests means the db can be in an inconsistent state between the two requests and the markup doesn't match the javascript. For this to work the js and markup need to be authored in the same request. I'm really interested in trying the data URL approach. No state of any kind required, no additional request, no additional Dispatcher, just a little change in the way JavaScript is added to the page. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load?
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java lance.j...@googlemail.com wrote: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load? Not to mention that JavaScriptSupport.addScript() is deprecated. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...)
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...) I guess event handlers should be registered in completely different way - using ids, CSS classes or data- attributes. More like the standard jQuery way with selectors and on: $( #myTable tr ).on( click, function() { alert( $( this ).attr(data-id) ); }); So, all the JS for a component should be in the JS. So maybe the whole JavaScriptSupport class should be deprecated? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 14:01:16 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: I guess event handlers should be registered in completely different way - using ids, CSS classes or data- attributes. More like the standard jQuery way with selectors and on: $( #myTable tr ).on( click, function() { alert( $( this ).attr(data-id) ); }); That's what Tapestry 5.4 does in its components. So, all the JS for a component should be in the JS. But the JS file still needs to be included in the HTML. So maybe the whole JavaScriptSupport class should be deprecated? How would JavaScript files be included by pages and components? Do you have any suggestion on how a JavaScriptSupport-less Tapestry would work in relation to JavaScript? I'm sorry, I just cannot see how (nor why). -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 13:35:01 -0200, Lance Java lance.j...@googlemail.com wrote: Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...) I don't think so. addScript() adds arbitrary JavaScript, so that may be a problem if a remote attacker creates some way of calling it. JavaScriptSupport.require() doesn't add arbitrary JavaScript: it just adds calls to the JS function require(). -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
I have a sneaking suspicion that trying to implement this you would end up writing a custom implementation of script and eval(...) to achieve tapestry's current behaviour :) On 4 Feb 2014 16:01, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...) I guess event handlers should be registered in completely different way - using ids, CSS classes or data- attributes. More like the standard jQuery way with selectors and on: $( #myTable tr ).on( click, function() { alert( $( this ).attr(data-id) ); }); So, all the JS for a component should be in the JS. So maybe the whole JavaScriptSupport class should be deprecated? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java lance.j...@googlemail.com wrote: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load? Reading the linked Wikipedia article, that's the only solution I can think of. I think it could be done with just a couple changes and a new Dispatcher. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Reading the linked Wikipedia article, that's the only solution I can think of. I think it could be done with just a couple changes and a new Dispatcher. It's tricky because there would be 2 requests (1 for markup and 1 for javascript).
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 14:32:52 -0200, Lance Java lance.j...@googlemail.com wrote: I have a sneaking suspicion that trying to implement this you would end up writing a custom implementation of script and eval(...) to achieve tapestry's current behaviour Nope, I was thinking of encoding the JavaScript code in the URL, probably in Base64, and write a Dispatcher that would catch these requests, extract the code from the URL and return it. Or store the code in memory, put a token in the URL and use the token to retrieve the stored code. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
I hate both ideas! Encoding in the URL means a useless request and will have issues with maximum url length. A token requires serverside state and relies on some form of time to live.
Re: Content Security Policy without unsafe-inline
I also think encoding in the URL opens up a security hole.
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 15:20:25 -0200, Lance Java lance.j...@googlemail.com wrote: I hate both ideas! Encoding in the URL means a useless request and will have issues with maximum url length. And security, as you cited in another e-mail, but only if the attacker manages to change the generated HTML to include the JavaScript URL, but, if they can already change the generated HTML, security is already lost. A token requires serverside state and relies on some form of time to live. Actually, the token and its corresponding state would be thrown off after used, so it wouldn't have much of a memory load. The use of some caching library would solve the time to live problem, and the time to live itself would be quite short. There are the two solutions I can see for anyone who wants to use Content Security Policy. There's no free lunch. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
If there was no time to live I could kill your server by requesting lots of pages and never requesting the javascript :) If url encoding I could get your cookie if you visit my (external) site which includes a script from your site.
Re: Content Security Policy without unsafe-inline
2014-02-04 Thiago H de Paula Figueiredo thiag...@gmail.com: How would JavaScript files be included by pages and components? Do you have any suggestion on how a JavaScriptSupport-less Tapestry would work in relation to JavaScript? I'm sorry, I just cannot see how (nor why). Easy, just the way require.js works :) // MyComp.java @Import(library = MyComp.js) public class MyComp { } // MyComp.js require( ['t5/core/console], function( console ) { console.log('lala'); }); If you need any data in your script, then just add the stuff to your DOM, e.g. with data- attributes or hidden fields. See http://www.requirejs.org/docs/start.html - there's no example with inline JS. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 15:58:46 -0200, Lance Java lance.j...@googlemail.com wrote: If there was no time to live I never suggested that. Of course there would be a time to live. Caches can be easily configured to do that. If url encoding I could get your cookie if you visit my (external) site which includes a script from your site. Yep, bad idea. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Agreed that the only reasonable solution is a token + ttl. I'm not convinced it's a good idea though.
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
I happen to be a fan of tapestry's multi-page approach and serverside markup generation. On 4 Feb 2014 18:35, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). Most methods in JavaScriptSupport are deprecated anyway. JavaScriptSupport#require could be removed again (requiring could be done by @Import). Voila - no inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 16:34:45 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. It's not about inline JavaScript. And I agree that it should be avoided. I think you're overlooking something: the fact that, sometimes, JavaScript needs to be dynamically generated server-side because it needs dynamic information. And one solution for doing this is to generate inline JavaScript. The other solution would be to have an AJAX request to do it, but then it's another request and it would slow down stuff a lot. And, again, let me remember you that Tapestry is already doing what you're asking in most places. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). I don't know a politer way of saying this, but I already said that Tapestry 5.4 is already doing that at least twice. I'm having a really unlucky day. :( -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org