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.
Freeze Colums in Grid
Hi. I want to freeze first 2 columns in grid. How I can do this in Tapestry5.3? About ideas and opportunities I am pleased.
Re: Freeze Colums in Grid
2014-02-05 Wasaj Wasd wasti...@gmail.com: I want to freeze first 2 columns in grid. How I can do this in Tapestry5.3? What do you mean by freeze? Disabled sorting? Another kind of style? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Freeze Colums in Grid
I think this is about being able to scroll horizontally int he browser and yet keeping the first 2 columns on the screen, as described here: http://stackoverflow.com/questions/1312236/how-do-i-create-an-html-table-with-fixed-frozen-left-column-and-scrollable-body But since the Tapestry Grid component outputs an ordinary HTML table, I think the solution will not be Tapestry-specific, so maybe the question is better asked on another forum. On Wed, Feb 5, 2014 at 11:06 AM, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-05 Wasaj Wasd wasti...@gmail.com: I want to freeze first 2 columns in grid. How I can do this in Tapestry5.3? What do you mean by freeze? Disabled sorting? Another kind of style? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - 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 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
