> What's annoying is that if Tapestry created some HTML5 elements for this
purpose; say and ; 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
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
alert("hello ${user}");
<\t:script>
That becomes something like:
which returns:
define(["jquery"], function(jquery) {
alert("hello Barry");
}
Th
I agree; this is an ugly hack to satisfy the arbitrary CSP requirement.
On Thu, Feb 6, 2014 at 5:20 AM, Lance Java wrote:
> In theory, the data URL approach sounds perfect.
>
> But in reality we'd be swapping this:
>alert('hello');
>
> For this:
>
>
> As you mentioned, it's likely that a
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 th
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 li
In theory, the data URL approach sounds perfect.
But in reality we'd be swapping this:
alert('hello');
For this:
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 (
On Wed, 05 Feb 2014 17:28:23 -0200, Lance Java
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
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 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
wrote:
> > The reason I wrot
> The reason I wrote the session cache was to support clustering.
I'm against the idea of forcing a session to support this.
> 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.
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.
On Wed, 05 Feb 2014 11:37:36 -0200, Lance Java
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 t
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 t
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"
wrote:
> On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java
> wrote:
>
> Any thoughts on using a data uri?
>>
>
> Good catch, Lance. Supposing browsers support it, and I d
On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java
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
h
Any thoughts on using a data uri?
http://en.m.wikipedia.org/wiki/Data_URI_scheme
On 5 Feb 2014 13:13, "Lance Java" wrote:
> Another consideration with the token approach is clustering. Either a
> sticky session or a distributed cache are required.
>
Another consideration with the token approach is clustering. Either a
sticky session or a distributed cache are required.
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 implementat
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" wro
On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic
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
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.
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.
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 con
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 gene
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 t
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
On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl
wrote:
2014-02-04 Lance Java :
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
On Tue, 04 Feb 2014 16:34:45 -0200, Christian Köberl
wrote:
2014-02-04 Lance Java :
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
2014-02-04 Lance Java :
> 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 in
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 :
> > It's tricky because there would be 2 requests (1 for markup and 1 for
> > javascript).
>
>
2014-02-04 Lance Java :
> 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
Agreed that the only reasonable solution is a token + ttl. I'm not
convinced it's a good idea though.
On Tue, 04 Feb 2014 15:58:46 -0200, Lance Java
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 scrip
2014-02-04 Thiago H de Paula Figueiredo :
> 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
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.
On Tue, 04 Feb 2014 15:20:25 -0200, Lance Java
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 Ja
I also think encoding in the URL opens up a security hole.
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.
On Tue, 04 Feb 2014 14:32:52 -0200, Lance Java
wrote:
I have a sneaking suspicion that trying to implement this you would end
up writing a custom implementation of
> 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).
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java
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 c
I have a sneaking suspicion that trying to implement this you would end up
writing a custom implementation of
On Tue, 04 Feb 2014 13:35:01 -0200, Lance Java
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 creat
On Tue, 04 Feb 2014 14:01:16 -0200, Christian Köberl
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(
2014-02-04 Lance Java :
>>> 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 i
> Not to mention that JavaScriptSupport.addScript() is deprecated.
The same question applies to JavaScriptSupport.require(...)
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java
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 Figue
How would you propose JavaScriptSupport.addScript(...) would work without
inline scripts? Do you expect a custom javascript file per page load?
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
50 matches
Mail list logo
