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!).
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
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
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
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
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
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
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
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
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
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.
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.
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.
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
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
Another consideration with the token approach is clustering. Either a
sticky session or a distributed cache are required.
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.
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
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.
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
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
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.
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.
The reason I wrote the session cache was to support clustering.
I'm against the idea of forcing a session to support this.
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
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.
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.
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).
How would you propose JavaScriptSupport.addScript(...) would work without
inline scripts? Do you expect a custom javascript file per page load?
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.
Not to mention that JavaScriptSupport.addScript() is deprecated.
The same question applies to JavaScriptSupport.require(...)
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
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(
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
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
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
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 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
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.
I also think encoding in the URL opens up a security hole.
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
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.
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
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)
Agreed that the only reasonable solution is a token + ttl. I'm not
convinced it's a good idea though.
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
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
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
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 -
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
50 matches
Mail list logo
