Content Security Policy without unsafe-inline

[Christian Köberl <ta...@gmail.com>]

I'm trying to add CSP
(https://en.wikipedia.org/wiki/Content_Security_Policy) to a Tapestry
application.

The problem is that I have to add "unsafe-inline" because Tapestry
adds all the initializing stuff in an inline <script> Block at the
bottom. That's making XSS attacks easier (or even possible).

Is there a way to prevent that in 5.3 and are there any plans on
getting rid of this "old-school" stuff in 5.4?

-- 
Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 13:35:01 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Howard Lewis Ship <hl...@gmail.com>]

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.marinkovic@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 <
> thiagohp@gmail.com> wrote:
>
> > On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl <
> > tapestry.christian.koeberl@gmail.com> wrote:
> >
> >  2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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

[Chris Mylonas <ch...@opencsta.org>]

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" <la...@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

[Lance Java <la...@googlemail.com>]

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

[Lance Java <la...@googlemail.com>]

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

[Chris Mylonas <ch...@opencsta.org>]

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" <kr...@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 <
> thiagohp@gmail.com> wrote:
>
> > On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl <
> > tapestry.christian.koeberl@gmail.com> wrote:
> >
> >  2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>

Re: Content Security Policy without unsafe-inline

[Chris Mylonas <ch...@opencsta.org>]

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" <la...@googlemail.com> wrote:

> In theory, the data URL approach sounds perfect.
>
> But in reality we'd be swapping this:
>    <script>alert('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

[Lance Java <la...@googlemail.com>]

> 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

[Barry Books <tr...@gmail.com>]

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 <la...@googlemail.com>wrote:

> In theory, the data URL approach sounds perfect.
>
> But in reality we'd be swapping this:
>    <script>alert('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

[Howard Lewis Ship <hl...@gmail.com>]

I agree; this is an ugly hack to satisfy the arbitrary CSP requirement.


On Thu, Feb 6, 2014 at 5:20 AM, Lance Java <la...@googlemail.com>wrote:

> In theory, the data URL approach sounds perfect.
>
> But in reality we'd be swapping this:
>    <script>alert('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

[Lance Java <la...@googlemail.com>]

In theory, the data URL approach sounds perfect.

But in reality we'd be swapping this:
   <script>alert('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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Wed, 05 Feb 2014 17:28:23 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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

[Barry Books <tr...@gmail.com>]

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 <la...@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

[Lance Java <la...@googlemail.com>]

> 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

[Lance Java <la...@googlemail.com>]

> 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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Wed, 05 Feb 2014 11:37:36 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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

[Barry Books <tr...@gmail.com>]

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 <la...@googlemail.com>wrote:

> 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" <th...@gmail.com>
> wrote:
>
> > On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java <
> lance.java@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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" <th...@gmail.com>
wrote:

> On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

Any thoughts on using a data uri?

http://en.m.wikipedia.org/wiki/Data_URI_scheme
 On 5 Feb 2014 13:13, "Lance Java" <la...@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

[Lance Java <la...@googlemail.com>]

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

[Barry Books <tr...@gmail.com>]

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 <
thiagohp@gmail.com> wrote:

> On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic <
> kristian.marinkovic@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic  
<kr...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Kristian Marinkovic <kr...@gmail.com>]

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 <la...@googlemail.com>wrote:

> 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

[Lance Java <la...@googlemail.com>]

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

[Kristian Marinkovic <kr...@gmail.com>]

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 <
thiagohp@gmail.com> wrote:

> On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl <
> tapestry.christian.koeberl@gmail.com> wrote:
>
>  2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl  
<ta...@gmail.com> wrote:

> 2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Christian Köberl <ta...@gmail.com>]

2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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.koeberl@gmail.com> wrote:

> 2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 16:34:45 -0200, Christian Köberl  
<ta...@gmail.com> wrote:

> 2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Christian Köberl <ta...@gmail.com>]

2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 15:58:46 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 15:20:25 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

I also think encoding in the URL opens up a security hole.

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 14:32:52 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

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.koeberl@gmail.com> wrote:

> 2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Content Security Policy without unsafe-inline

[Christian Köberl <ta...@gmail.com>]

2014-02-04 Thiago H de Paula Figueiredo <th...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 14:01:16 -0200, Christian Köberl  
<ta...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Christian Köberl <ta...@gmail.com>]

2014-02-04 Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

> Not to mention that JavaScriptSupport.addScript() is deprecated.

The same question applies to JavaScriptSupport.require(...)

Re: Content Security Policy without unsafe-inline

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

> 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

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java <la...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Content Security Policy without unsafe-inline

[Lance Java <la...@googlemail.com>]

How would you propose JavaScriptSupport.addScript(...) would work without
inline scripts? Do you expect a custom javascript file per page load?