You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Tine <ch...@gmail.com> on 2006/11/15 11:32:41 UTC
Re: dialog problem in the latest 4.1.1 snapshot
Hello,
I have another problem with my dialog:
org.apache.tapestry.BindingException: Binding for parameter hidden default
value (ExpressionBinding[... true]) may not be updated.
[classpath:/org/apache/tapestry/dojo/html/Dialog.jwc, line 29, column 53]
at
org.apache.tapestry.binding.AbstractBinding.createReadOnlyBindingException(AbstractBinding.java:114)
at
org.apache.tapestry.binding.ExpressionBinding.setObject(ExpressionBinding.java:166)
at $Dialog_1030.setHidden($Dialog_1030.java)
at org.apache.tapestry.dojo.html.Dialog.show(Dialog.java:43)
...
In .page file:
<component id="aDialog" type="Dialog"/>
I want to show the dialog by clicking an async. DirectLink.
Listener:
public void listen() {
Dialog dialog = ((Dialog)getComponent("aDialog"));
dialog.show();
}
After dialog.show() I get the exception. Can anyone help me please?
Regards,
Tine
Norbert Sándor wrote:
>
> Sorry, I wanted to send this to the user list instead the developer:
>
> Hi,
>
> The dojo dialog has problems in the latest svn version: on long pages,
> if I scroll down the page, the dialog is displayed incorrectly and it is
> not modal: the element which is displayed behind the dialog to hide the
> page's content is displayed incorrectly.
> See this screenshot: http://www.erinors.com/temp/dojo_dialog.jpg
>
> The same error is reproducable at
> http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html
>
> The dialog worked correctly with 4.1.1's previous dojo version.
>
> What do you recommend?
> Can I switch to the official 3.1 release without breaking tapestry
> client side functionality?
>
> Regards,
> Norbi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/dialog-problem-in-the-latest-4.1.1-snapshot-tf2371912.html#a7355371
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: preventing double submit in tapestry
Posted by Nick Westgate <ni...@key-planning.co.jp>.
No argument there. But like any respectable programmer, I am lazy. ;-)
I'm using a framework to take the drudgery out of web programming.
Do I have to add disabling code for every request-sending widget?
If the answer is yes then ... this is why I have not done it!
(When a client has requested disabled/hidden buttons etc, I've done it,
but as I said before, in T3 this server-side trickery is required.)
Cheers,
Nick.
Jesse Kuhnert wrote:
> And where exactly does the "user experience" fit in to all of this cool
> server side trickery? I mean, even in a basic swing application I would
> disable input on things people aren't allowed to use when I'm doing
> something that will potentially take a long time to complete.
>
> The browser is your friend, not a place where scary hacks happen. It's your
> UI, embrace it. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: preventing double submit in tapestry
Posted by Jesse Kuhnert <jk...@gmail.com>.
And where exactly does the "user experience" fit in to all of this cool
server side trickery? I mean, even in a basic swing application I would
disable input on things people aren't allowed to use when I'm doing
something that will potentially take a long time to complete.
The browser is your friend, not a place where scary hacks happen. It's your
UI, embrace it. ;)
On 11/15/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
>
> IMO, disabling a submit with javascript is a hack. The problem is common,
> and a natural consequence of using Tapestry to develop a web application.
> Tapestry should be taking care of it for us.
>
> In any case, this can be solved in the same way that the old "locked after
> a commit()" errors in T3 were. I think T4 (via hivemind?) has fixed that
> particular incarnation. (It happened with all kinds of requests, and when
> using frames etc.)
>
> Use a filter to queue requests from the same client, or discard new ones:
> http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html
>
> Use a Flow Synchronizer to handle form reposts:
> http://www.junlu.com/msg/85270.html
>
> I find the Flow Synchronizer particularly useful, as I put the bean in my
> border component and add handling methods to my base page class. Methods
> such as a simple isRepost() allow special casing the request - to avoid
> repeating a delete, for instance, but allowing other reposts to proceed.
>
> You'll find plenty of posts on the above topics in the list archives.
>
> Cheers,
> Nick.
>
>
> John Menke wrote:
> > The filter solution does use a unique token on the form and you can
> disable
> > the filter by not including the token on a form. I did have to add
> > logic to
> > the posted solution to handle errors but even with that code included
> the
> > code seems to be non-invasive -- all it does is check for form variable
> and
> > continues normal processing or blocks duplicate requests while "caching"
> > the
> > response (sounds more complicated than it is)
> >
> > i do see what you mean about the security concern and someone being able
> to
> > manipulate a post to get past the filter, trying to think of solutions
> to
> > this problem
> >
> > maybe something where the form included a secure key in a hidden
> variable
> > and having some sort of check which could determine if a key had been
> used
> > already
> >
> > if form is secure
> > -- check for valid and unique key
> > -- if key is valid then process the form and expire the key
> > -- don't let another request pass through after key is expired or absent
> >
> > above solution does require the ability to mark certain forms as secure
> on
> > the server side.
> >
> > with security in place i think the filter solution could be a complete
> > server side solution. I know you mentioned possible side effects did
> you
> > have anything specific in mind?
> >
> > Bottom line is that there should be a server side solution to this
> problem
> > in tapestry that is secure and non-invasive. I encourage others to post
> > their ideas in an effort to come to some sort of agreement on best way
> to
> > accomplish this.
> >
> > -john
> >
> >
> >
> > On 11/15/06, Sam Gendler <sg...@ideasculptor.com> wrote:
> >>
> >> That seems like a complex solution to the problem which does things in
> >> a filter, where it might be difficult to predict side effects or
> >> override the behaviour in certain circumstances. I'd be more inclined
> >> to implement a unique token solution in a base page class so that I
> >> could overload it in certain pages, if necessary. Simplest solution,
> >> but not entirely error proof, would be to stick a unique token in the
> >> form (I'm not use you can use a session persistent property in the
> >> page, as I don't know when those get written into the session -
> >> possibly only after the page is finished processing). Then, when
> >> processing any form, check the session location for a token, if it
> >> matches, just send back a page saying "don't do that." If it isn't
> >> found, assume that this is the first time you've seen the form and go
> >> ahead and process it. You can add increasing complexity to such a
> >> solution depending on what kind of user experience you want and how
> >> error-proof you want it. The filter trick is cute, since you can
> >> actually serve the same response to multiple requests, but that is
> >> often not necessary and sometimes not even desired and it takes too
> >> much logic out of the core application for my own comfort level.
> >>
> >> But disabling a button can be pretty effective against all but an
> >> actually malicious user (does anyone build javascript-free web apps
> >> these days, especially in tapestry?), and a malicious user can
> >> override a unique token all too easily, anyway. If there is a true
> >> security or data integrity concern, you'll have to do something that
> >> is entirely on the server side in order to prevent manipulation by
> >> someone with the smarts to interpret an html file and manually send a
> >> post.
> >>
> >> --sam
> >>
> >> On 11/15/06, John Menke <jm...@gmail.com> wrote:
> >> > Is there a non-javascript solution to this problem? I have been
> >> > experimenting with code based on the forum post below. Has anyone
> >> developed
> >> > a solution for Tapestry? I propose some sort of consensus should
> >> > be reached as to what the best method is to handle double submits and
> a
> >> > patch should be made for Tapestry. Any comments? Ideas?
> >> >
> >> > <quote from Forum Post>
> >> > There is a server-side solution for this problem. Here is the
> concept:
> >> > Build a way to identify each form from which a request (or multiple
> >> > requests, if the form button is clicked several times) arrives. This
> >> can
> >> be
> >> > done by having a hidden input element included in the form, whose
> value
> >> is a
> >> > unique number (typically using the time in milliseconds).
> >> >
> >> > Write a filter implementing the javax.servlet.Filter interface, with
> >> the
> >> > following logic in the doFilter() method:
> >> > Synchronize a code block on a session-scoped object. Inside this
> block,
> >> > check if the form-id received through the current request is same as
> >> the
> >> one
> >> > received previously.
> >> > If different, this is the first request received from the form (i.e.
> >> the
> >> > request originated as a result of the first click). If same, this is
> a
> >> > subsequent request, generated as a result of multiple clicks.
> >> >
> >> > In the first case, invoke FilterChain.doFilter() by passing a
> >> > ResponseWrapper object instead of the original response object. This
> >> > ResponseWrapper object should be built with a ByteArrayOutputStream
> >> object,
> >> > so that the response content can be extracted as a String. When the
> >> > FilterChain.doFilter() method returns, save the response content and
> >> the
> >> > current form-id in session-scope, for subsequent requests and leave
> the
> >> > synchronized block.
> >> >
> >> > Then outside the synchronized block, forward all the requests
> >> (including
> >> the
> >> > first one) to a "LoopBackServlet" with the original "request" and
> >> "response"
> >> > objects. The whole purpose of this "LoopBackServlet" is to write the
> >> saved
> >> > response content into the response object.
> >> >
> >> > In this way, when multiple requests arrive from the same form as a
> >> result of
> >> > multiple clicks, we let the first request thread proceed, with a
> >> > response-wrapper and block all the other threads. When the first
> thread
> >> > returns with the response ready, the response content is stored in
> >> session
> >> > and the same is written to all the blocked threads when they become
> >> > unblocked.
> >> >
> >> > If anybody wants more details, please email me at
> >> shaikbash@yahoo.com, I
> >> can
> >> > send the working code.
> >> >
> >> >
> >> > </quote from Forum Post>
> >> >
> >> >
> http://forum.java.sun.com/thread.jspa?threadID=665472&start=15&tstart=0
> >> >
> >> >
> >> >
> >> > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> >> > >
> >> > > I was looking for a sledgehammer to crack a nut. That's how I
> >> ended up
> >> > > doing it (after spending the day looking for an enterprisey
> >> solution!)
> >> > > Thanks
> >> > > Denis
> >> > >
> >> > > Jesse Kuhnert wrote:
> >> > > > Why don't you just disable the submit buttons in question when
> they
> >> > > submit?
> >> > > > (set the disabled attribute to true)
> >> > > >
> >> > > > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> >> > > >>
> >> > > >> Hi,
> >> > > >> I'm encountering a problem in my app where users are double
> >> submitting
> >> > > a
> >> > > >> form, creating a hibernate exception in the back end where two
> >> > > >> sessions are attempting to update the same collection. I've read
> >> some
> >> > > >> posts about preventing form resubmission by using a unique
> >> token in
> >> the
> >> > > >> form to detect a double submit.
> >> > > >>
> >> > > >> If a double submit is detected, the second and subsequent
> submits
> >> wait
> >> > > >> until the original one returns and then report the outcome of
> that
> >> > > >> transaction (if I understand correctly, it's the last submit
> that
> >> > > issues
> >> > > >> the response to the user, and the first one does the updating).
> >> > > >>
> >> > > >> I'm wondering
> >> > > >> a) is this indeed the right approach to stop users who are
> >> > > >> over-enthusiastic in their button clicking from encountering
> >> errors,
> >> > > and
> >> > > >> b) does anyone have an actual example of code that implements
> this
> >> > > >> pattern?
> >> > > >> Thanks very much
> >> > > >> Denis Mc.
> >> > > >>
> >> > > >>
> >> ---------------------------------------------------------------------
> >> > > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
RE: Help with ognl...
Posted by Mark Stang <ms...@pingidentity.com>.
Robert,
Good catch, I had "false" in there before, but it complained about trying to init a Boolean with a String and it couldn't convert it. I copied/pasted from an HTML template and picked up the extra "ognl". Once I removed that, it worked!
Thanks!
regards,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
-----Original Message-----
From: Robert Zeigler [mailto:robertz@scazdl.org]
Sent: Wed 11/22/2006 12:01 PM
To: Tapestry users
Subject: Re: Help with ognl...
the binding type for default-value is already ognl. So ognl is chocking
on the ognl: part. Try something like:
default-value="false"
:)
Robert
Mark Stang wrote:
> I am trying to create a 3.x parameter:
>
> <parameter name="maskValues" type="java.lang.Boolean" required="no" direction="in" default-value="ognl:@java.lang.Boolean@FALSE"/>
>
> I was using a "boolean", but there is a bug in 3.x where sometimes it doesn't pass the value in, so I switched to a Boolean, but can't seem to come up with a valid default value.
>
> Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
> binding: ExpressionBinding[Holder/createAdapterContract.$AttributeContractEditor ognl:@java.lang.Boolean@FALSE]
> location: classpath:/com/pingidentity/component/common/AttributeContractEditor.jwc, line 17, column 135
>
> org.apache.tapestry.ApplicationRuntimeException
> Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
>
> ognl.ExpressionSyntaxException
> Malformed OGNL expression: ognl:@java.lang.Boolean@FALSE
>
> Thoughts?
>
> thanks,
>
> Mark
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Help with ognl...
Posted by Robert Zeigler <ro...@scazdl.org>.
the binding type for default-value is already ognl. So ognl is chocking
on the ognl: part. Try something like:
default-value="false"
:)
Robert
Mark Stang wrote:
> I am trying to create a 3.x parameter:
>
> <parameter name="maskValues" type="java.lang.Boolean" required="no" direction="in" default-value="ognl:@java.lang.Boolean@FALSE"/>
>
> I was using a "boolean", but there is a bug in 3.x where sometimes it doesn't pass the value in, so I switched to a Boolean, but can't seem to come up with a valid default value.
>
> Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
> binding: ExpressionBinding[Holder/createAdapterContract.$AttributeContractEditor ognl:@java.lang.Boolean@FALSE]
> location: classpath:/com/pingidentity/component/common/AttributeContractEditor.jwc, line 17, column 135
>
> org.apache.tapestry.ApplicationRuntimeException
> Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
>
> ognl.ExpressionSyntaxException
> Malformed OGNL expression: ognl:@java.lang.Boolean@FALSE
>
> Thoughts?
>
> thanks,
>
> Mark
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Help with ognl...
Posted by Mark Stang <ms...@pingidentity.com>.
I am trying to create a 3.x parameter:
<parameter name="maskValues" type="java.lang.Boolean" required="no" direction="in" default-value="ognl:@java.lang.Boolean@FALSE"/>
I was using a "boolean", but there is a bug in 3.x where sometimes it doesn't pass the value in, so I switched to a Boolean, but can't seem to come up with a valid default value.
Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
binding: ExpressionBinding[Holder/createAdapterContract.$AttributeContractEditor ognl:@java.lang.Boolean@FALSE]
location: classpath:/com/pingidentity/component/common/AttributeContractEditor.jwc, line 17, column 135
org.apache.tapestry.ApplicationRuntimeException
Unable to parse expression 'ognl:@java.lang.Boolean@FALSE'.
ognl.ExpressionSyntaxException
Malformed OGNL expression: ognl:@java.lang.Boolean@FALSE
Thoughts?
thanks,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
Re: EnumPropertySelectionModel - Tapestry 3.x
Posted by Jesse Kuhnert <jk...@gmail.com>.
http://tapestry.apache.org/tapestry4.1/apidocs/index.html
(notice the javadocs show you the source as well if you click on the class
name)
On 11/16/06, Mark Stang <ms...@pingidentity.com> wrote:
>
> Does anyone have one that is available that doesn't use a resource bundle?
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
EnumPropertySelectionModel - Tapestry 3.x
Posted by Mark Stang <ms...@pingidentity.com>.
Does anyone have one that is available that doesn't use a resource bundle?
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
Re: preventing double submit in tapestry
Posted by Nick Westgate <ni...@key-planning.co.jp>.
IMO, disabling a submit with javascript is a hack. The problem is common,
and a natural consequence of using Tapestry to develop a web application.
Tapestry should be taking care of it for us.
In any case, this can be solved in the same way that the old "locked after
a commit()" errors in T3 were. I think T4 (via hivemind?) has fixed that
particular incarnation. (It happened with all kinds of requests, and when
using frames etc.)
Use a filter to queue requests from the same client, or discard new ones:
http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html
Use a Flow Synchronizer to handle form reposts:
http://www.junlu.com/msg/85270.html
I find the Flow Synchronizer particularly useful, as I put the bean in my
border component and add handling methods to my base page class. Methods
such as a simple isRepost() allow special casing the request - to avoid
repeating a delete, for instance, but allowing other reposts to proceed.
You'll find plenty of posts on the above topics in the list archives.
Cheers,
Nick.
John Menke wrote:
> The filter solution does use a unique token on the form and you can disable
> the filter by not including the token on a form. I did have to add
> logic to
> the posted solution to handle errors but even with that code included the
> code seems to be non-invasive -- all it does is check for form variable and
> continues normal processing or blocks duplicate requests while "caching"
> the
> response (sounds more complicated than it is)
>
> i do see what you mean about the security concern and someone being able to
> manipulate a post to get past the filter, trying to think of solutions to
> this problem
>
> maybe something where the form included a secure key in a hidden variable
> and having some sort of check which could determine if a key had been used
> already
>
> if form is secure
> -- check for valid and unique key
> -- if key is valid then process the form and expire the key
> -- don't let another request pass through after key is expired or absent
>
> above solution does require the ability to mark certain forms as secure on
> the server side.
>
> with security in place i think the filter solution could be a complete
> server side solution. I know you mentioned possible side effects did you
> have anything specific in mind?
>
> Bottom line is that there should be a server side solution to this problem
> in tapestry that is secure and non-invasive. I encourage others to post
> their ideas in an effort to come to some sort of agreement on best way to
> accomplish this.
>
> -john
>
>
>
> On 11/15/06, Sam Gendler <sg...@ideasculptor.com> wrote:
>>
>> That seems like a complex solution to the problem which does things in
>> a filter, where it might be difficult to predict side effects or
>> override the behaviour in certain circumstances. I'd be more inclined
>> to implement a unique token solution in a base page class so that I
>> could overload it in certain pages, if necessary. Simplest solution,
>> but not entirely error proof, would be to stick a unique token in the
>> form (I'm not use you can use a session persistent property in the
>> page, as I don't know when those get written into the session -
>> possibly only after the page is finished processing). Then, when
>> processing any form, check the session location for a token, if it
>> matches, just send back a page saying "don't do that." If it isn't
>> found, assume that this is the first time you've seen the form and go
>> ahead and process it. You can add increasing complexity to such a
>> solution depending on what kind of user experience you want and how
>> error-proof you want it. The filter trick is cute, since you can
>> actually serve the same response to multiple requests, but that is
>> often not necessary and sometimes not even desired and it takes too
>> much logic out of the core application for my own comfort level.
>>
>> But disabling a button can be pretty effective against all but an
>> actually malicious user (does anyone build javascript-free web apps
>> these days, especially in tapestry?), and a malicious user can
>> override a unique token all too easily, anyway. If there is a true
>> security or data integrity concern, you'll have to do something that
>> is entirely on the server side in order to prevent manipulation by
>> someone with the smarts to interpret an html file and manually send a
>> post.
>>
>> --sam
>>
>> On 11/15/06, John Menke <jm...@gmail.com> wrote:
>> > Is there a non-javascript solution to this problem? I have been
>> > experimenting with code based on the forum post below. Has anyone
>> developed
>> > a solution for Tapestry? I propose some sort of consensus should
>> > be reached as to what the best method is to handle double submits and a
>> > patch should be made for Tapestry. Any comments? Ideas?
>> >
>> > <quote from Forum Post>
>> > There is a server-side solution for this problem. Here is the concept:
>> > Build a way to identify each form from which a request (or multiple
>> > requests, if the form button is clicked several times) arrives. This
>> can
>> be
>> > done by having a hidden input element included in the form, whose value
>> is a
>> > unique number (typically using the time in milliseconds).
>> >
>> > Write a filter implementing the javax.servlet.Filter interface, with
>> the
>> > following logic in the doFilter() method:
>> > Synchronize a code block on a session-scoped object. Inside this block,
>> > check if the form-id received through the current request is same as
>> the
>> one
>> > received previously.
>> > If different, this is the first request received from the form (i.e.
>> the
>> > request originated as a result of the first click). If same, this is a
>> > subsequent request, generated as a result of multiple clicks.
>> >
>> > In the first case, invoke FilterChain.doFilter() by passing a
>> > ResponseWrapper object instead of the original response object. This
>> > ResponseWrapper object should be built with a ByteArrayOutputStream
>> object,
>> > so that the response content can be extracted as a String. When the
>> > FilterChain.doFilter() method returns, save the response content and
>> the
>> > current form-id in session-scope, for subsequent requests and leave the
>> > synchronized block.
>> >
>> > Then outside the synchronized block, forward all the requests
>> (including
>> the
>> > first one) to a "LoopBackServlet" with the original "request" and
>> "response"
>> > objects. The whole purpose of this "LoopBackServlet" is to write the
>> saved
>> > response content into the response object.
>> >
>> > In this way, when multiple requests arrive from the same form as a
>> result of
>> > multiple clicks, we let the first request thread proceed, with a
>> > response-wrapper and block all the other threads. When the first thread
>> > returns with the response ready, the response content is stored in
>> session
>> > and the same is written to all the blocked threads when they become
>> > unblocked.
>> >
>> > If anybody wants more details, please email me at
>> shaikbash@yahoo.com, I
>> can
>> > send the working code.
>> >
>> >
>> > </quote from Forum Post>
>> >
>> > http://forum.java.sun.com/thread.jspa?threadID=665472&start=15&tstart=0
>> >
>> >
>> >
>> > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
>> > >
>> > > I was looking for a sledgehammer to crack a nut. That's how I
>> ended up
>> > > doing it (after spending the day looking for an enterprisey
>> solution!)
>> > > Thanks
>> > > Denis
>> > >
>> > > Jesse Kuhnert wrote:
>> > > > Why don't you just disable the submit buttons in question when they
>> > > submit?
>> > > > (set the disabled attribute to true)
>> > > >
>> > > > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
>> > > >>
>> > > >> Hi,
>> > > >> I'm encountering a problem in my app where users are double
>> submitting
>> > > a
>> > > >> form, creating a hibernate exception in the back end where two
>> > > >> sessions are attempting to update the same collection. I've read
>> some
>> > > >> posts about preventing form resubmission by using a unique
>> token in
>> the
>> > > >> form to detect a double submit.
>> > > >>
>> > > >> If a double submit is detected, the second and subsequent submits
>> wait
>> > > >> until the original one returns and then report the outcome of that
>> > > >> transaction (if I understand correctly, it's the last submit that
>> > > issues
>> > > >> the response to the user, and the first one does the updating).
>> > > >>
>> > > >> I'm wondering
>> > > >> a) is this indeed the right approach to stop users who are
>> > > >> over-enthusiastic in their button clicking from encountering
>> errors,
>> > > and
>> > > >> b) does anyone have an actual example of code that implements this
>> > > >> pattern?
>> > > >> Thanks very much
>> > > >> Denis Mc.
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > >> For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: preventing double submit in tapestry
Posted by John Menke <jm...@gmail.com>.
The filter solution does use a unique token on the form and you can disable
the filter by not including the token on a form. I did have to add logic to
the posted solution to handle errors but even with that code included the
code seems to be non-invasive -- all it does is check for form variable and
continues normal processing or blocks duplicate requests while "caching" the
response (sounds more complicated than it is)
i do see what you mean about the security concern and someone being able to
manipulate a post to get past the filter, trying to think of solutions to
this problem
maybe something where the form included a secure key in a hidden variable
and having some sort of check which could determine if a key had been used
already
if form is secure
-- check for valid and unique key
-- if key is valid then process the form and expire the key
-- don't let another request pass through after key is expired or absent
above solution does require the ability to mark certain forms as secure on
the server side.
with security in place i think the filter solution could be a complete
server side solution. I know you mentioned possible side effects did you
have anything specific in mind?
Bottom line is that there should be a server side solution to this problem
in tapestry that is secure and non-invasive. I encourage others to post
their ideas in an effort to come to some sort of agreement on best way to
accomplish this.
-john
On 11/15/06, Sam Gendler <sg...@ideasculptor.com> wrote:
>
> That seems like a complex solution to the problem which does things in
> a filter, where it might be difficult to predict side effects or
> override the behaviour in certain circumstances. I'd be more inclined
> to implement a unique token solution in a base page class so that I
> could overload it in certain pages, if necessary. Simplest solution,
> but not entirely error proof, would be to stick a unique token in the
> form (I'm not use you can use a session persistent property in the
> page, as I don't know when those get written into the session -
> possibly only after the page is finished processing). Then, when
> processing any form, check the session location for a token, if it
> matches, just send back a page saying "don't do that." If it isn't
> found, assume that this is the first time you've seen the form and go
> ahead and process it. You can add increasing complexity to such a
> solution depending on what kind of user experience you want and how
> error-proof you want it. The filter trick is cute, since you can
> actually serve the same response to multiple requests, but that is
> often not necessary and sometimes not even desired and it takes too
> much logic out of the core application for my own comfort level.
>
> But disabling a button can be pretty effective against all but an
> actually malicious user (does anyone build javascript-free web apps
> these days, especially in tapestry?), and a malicious user can
> override a unique token all too easily, anyway. If there is a true
> security or data integrity concern, you'll have to do something that
> is entirely on the server side in order to prevent manipulation by
> someone with the smarts to interpret an html file and manually send a
> post.
>
> --sam
>
> On 11/15/06, John Menke <jm...@gmail.com> wrote:
> > Is there a non-javascript solution to this problem? I have been
> > experimenting with code based on the forum post below. Has anyone
> developed
> > a solution for Tapestry? I propose some sort of consensus should
> > be reached as to what the best method is to handle double submits and a
> > patch should be made for Tapestry. Any comments? Ideas?
> >
> > <quote from Forum Post>
> > There is a server-side solution for this problem. Here is the concept:
> > Build a way to identify each form from which a request (or multiple
> > requests, if the form button is clicked several times) arrives. This can
> be
> > done by having a hidden input element included in the form, whose value
> is a
> > unique number (typically using the time in milliseconds).
> >
> > Write a filter implementing the javax.servlet.Filter interface, with the
> > following logic in the doFilter() method:
> > Synchronize a code block on a session-scoped object. Inside this block,
> > check if the form-id received through the current request is same as the
> one
> > received previously.
> > If different, this is the first request received from the form (i.e. the
> > request originated as a result of the first click). If same, this is a
> > subsequent request, generated as a result of multiple clicks.
> >
> > In the first case, invoke FilterChain.doFilter() by passing a
> > ResponseWrapper object instead of the original response object. This
> > ResponseWrapper object should be built with a ByteArrayOutputStream
> object,
> > so that the response content can be extracted as a String. When the
> > FilterChain.doFilter() method returns, save the response content and the
> > current form-id in session-scope, for subsequent requests and leave the
> > synchronized block.
> >
> > Then outside the synchronized block, forward all the requests (including
> the
> > first one) to a "LoopBackServlet" with the original "request" and
> "response"
> > objects. The whole purpose of this "LoopBackServlet" is to write the
> saved
> > response content into the response object.
> >
> > In this way, when multiple requests arrive from the same form as a
> result of
> > multiple clicks, we let the first request thread proceed, with a
> > response-wrapper and block all the other threads. When the first thread
> > returns with the response ready, the response content is stored in
> session
> > and the same is written to all the blocked threads when they become
> > unblocked.
> >
> > If anybody wants more details, please email me at shaikbash@yahoo.com, I
> can
> > send the working code.
> >
> >
> > </quote from Forum Post>
> >
> > http://forum.java.sun.com/thread.jspa?threadID=665472&start=15&tstart=0
> >
> >
> >
> > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> > >
> > > I was looking for a sledgehammer to crack a nut. That's how I ended up
> > > doing it (after spending the day looking for an enterprisey solution!)
> > > Thanks
> > > Denis
> > >
> > > Jesse Kuhnert wrote:
> > > > Why don't you just disable the submit buttons in question when they
> > > submit?
> > > > (set the disabled attribute to true)
> > > >
> > > > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> > > >>
> > > >> Hi,
> > > >> I'm encountering a problem in my app where users are double
> submitting
> > > a
> > > >> form, creating a hibernate exception in the back end where two
> > > >> sessions are attempting to update the same collection. I've read
> some
> > > >> posts about preventing form resubmission by using a unique token in
> the
> > > >> form to detect a double submit.
> > > >>
> > > >> If a double submit is detected, the second and subsequent submits
> wait
> > > >> until the original one returns and then report the outcome of that
> > > >> transaction (if I understand correctly, it's the last submit that
> > > issues
> > > >> the response to the user, and the first one does the updating).
> > > >>
> > > >> I'm wondering
> > > >> a) is this indeed the right approach to stop users who are
> > > >> over-enthusiastic in their button clicking from encountering
> errors,
> > > and
> > > >> b) does anyone have an actual example of code that implements this
> > > >> pattern?
> > > >> Thanks very much
> > > >> Denis Mc.
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: preventing double submit in tapestry
Posted by Sam Gendler <sg...@ideasculptor.com>.
That seems like a complex solution to the problem which does things in
a filter, where it might be difficult to predict side effects or
override the behaviour in certain circumstances. I'd be more inclined
to implement a unique token solution in a base page class so that I
could overload it in certain pages, if necessary. Simplest solution,
but not entirely error proof, would be to stick a unique token in the
form (I'm not use you can use a session persistent property in the
page, as I don't know when those get written into the session -
possibly only after the page is finished processing). Then, when
processing any form, check the session location for a token, if it
matches, just send back a page saying "don't do that." If it isn't
found, assume that this is the first time you've seen the form and go
ahead and process it. You can add increasing complexity to such a
solution depending on what kind of user experience you want and how
error-proof you want it. The filter trick is cute, since you can
actually serve the same response to multiple requests, but that is
often not necessary and sometimes not even desired and it takes too
much logic out of the core application for my own comfort level.
But disabling a button can be pretty effective against all but an
actually malicious user (does anyone build javascript-free web apps
these days, especially in tapestry?), and a malicious user can
override a unique token all too easily, anyway. If there is a true
security or data integrity concern, you'll have to do something that
is entirely on the server side in order to prevent manipulation by
someone with the smarts to interpret an html file and manually send a
post.
--sam
On 11/15/06, John Menke <jm...@gmail.com> wrote:
> Is there a non-javascript solution to this problem? I have been
> experimenting with code based on the forum post below. Has anyone developed
> a solution for Tapestry? I propose some sort of consensus should
> be reached as to what the best method is to handle double submits and a
> patch should be made for Tapestry. Any comments? Ideas?
>
> <quote from Forum Post>
> There is a server-side solution for this problem. Here is the concept:
> Build a way to identify each form from which a request (or multiple
> requests, if the form button is clicked several times) arrives. This can be
> done by having a hidden input element included in the form, whose value is a
> unique number (typically using the time in milliseconds).
>
> Write a filter implementing the javax.servlet.Filter interface, with the
> following logic in the doFilter() method:
> Synchronize a code block on a session-scoped object. Inside this block,
> check if the form-id received through the current request is same as the one
> received previously.
> If different, this is the first request received from the form (i.e. the
> request originated as a result of the first click). If same, this is a
> subsequent request, generated as a result of multiple clicks.
>
> In the first case, invoke FilterChain.doFilter() by passing a
> ResponseWrapper object instead of the original response object. This
> ResponseWrapper object should be built with a ByteArrayOutputStream object,
> so that the response content can be extracted as a String. When the
> FilterChain.doFilter() method returns, save the response content and the
> current form-id in session-scope, for subsequent requests and leave the
> synchronized block.
>
> Then outside the synchronized block, forward all the requests (including the
> first one) to a "LoopBackServlet" with the original "request" and "response"
> objects. The whole purpose of this "LoopBackServlet" is to write the saved
> response content into the response object.
>
> In this way, when multiple requests arrive from the same form as a result of
> multiple clicks, we let the first request thread proceed, with a
> response-wrapper and block all the other threads. When the first thread
> returns with the response ready, the response content is stored in session
> and the same is written to all the blocked threads when they become
> unblocked.
>
> If anybody wants more details, please email me at shaikbash@yahoo.com, I can
> send the working code.
>
>
> </quote from Forum Post>
>
> http://forum.java.sun.com/thread.jspa?threadID=665472&start=15&tstart=0
>
>
>
> On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> >
> > I was looking for a sledgehammer to crack a nut. That's how I ended up
> > doing it (after spending the day looking for an enterprisey solution!)
> > Thanks
> > Denis
> >
> > Jesse Kuhnert wrote:
> > > Why don't you just disable the submit buttons in question when they
> > submit?
> > > (set the disabled attribute to true)
> > >
> > > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> > >>
> > >> Hi,
> > >> I'm encountering a problem in my app where users are double submitting
> > a
> > >> form, creating a hibernate exception in the back end where two
> > >> sessions are attempting to update the same collection. I've read some
> > >> posts about preventing form resubmission by using a unique token in the
> > >> form to detect a double submit.
> > >>
> > >> If a double submit is detected, the second and subsequent submits wait
> > >> until the original one returns and then report the outcome of that
> > >> transaction (if I understand correctly, it's the last submit that
> > issues
> > >> the response to the user, and the first one does the updating).
> > >>
> > >> I'm wondering
> > >> a) is this indeed the right approach to stop users who are
> > >> over-enthusiastic in their button clicking from encountering errors,
> > and
> > >> b) does anyone have an actual example of code that implements this
> > >> pattern?
> > >> Thanks very much
> > >> Denis Mc.
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: preventing double submit in tapestry
Posted by John Menke <jm...@gmail.com>.
Is there a non-javascript solution to this problem? I have been
experimenting with code based on the forum post below. Has anyone developed
a solution for Tapestry? I propose some sort of consensus should
be reached as to what the best method is to handle double submits and a
patch should be made for Tapestry. Any comments? Ideas?
<quote from Forum Post>
There is a server-side solution for this problem. Here is the concept:
Build a way to identify each form from which a request (or multiple
requests, if the form button is clicked several times) arrives. This can be
done by having a hidden input element included in the form, whose value is a
unique number (typically using the time in milliseconds).
Write a filter implementing the javax.servlet.Filter interface, with the
following logic in the doFilter() method:
Synchronize a code block on a session-scoped object. Inside this block,
check if the form-id received through the current request is same as the one
received previously.
If different, this is the first request received from the form (i.e. the
request originated as a result of the first click). If same, this is a
subsequent request, generated as a result of multiple clicks.
In the first case, invoke FilterChain.doFilter() by passing a
ResponseWrapper object instead of the original response object. This
ResponseWrapper object should be built with a ByteArrayOutputStream object,
so that the response content can be extracted as a String. When the
FilterChain.doFilter() method returns, save the response content and the
current form-id in session-scope, for subsequent requests and leave the
synchronized block.
Then outside the synchronized block, forward all the requests (including the
first one) to a "LoopBackServlet" with the original "request" and "response"
objects. The whole purpose of this "LoopBackServlet" is to write the saved
response content into the response object.
In this way, when multiple requests arrive from the same form as a result of
multiple clicks, we let the first request thread proceed, with a
response-wrapper and block all the other threads. When the first thread
returns with the response ready, the response content is stored in session
and the same is written to all the blocked threads when they become
unblocked.
If anybody wants more details, please email me at shaikbash@yahoo.com, I can
send the working code.
</quote from Forum Post>
http://forum.java.sun.com/thread.jspa?threadID=665472&start=15&tstart=0
On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
>
> I was looking for a sledgehammer to crack a nut. That's how I ended up
> doing it (after spending the day looking for an enterprisey solution!)
> Thanks
> Denis
>
> Jesse Kuhnert wrote:
> > Why don't you just disable the submit buttons in question when they
> submit?
> > (set the disabled attribute to true)
> >
> > On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
> >>
> >> Hi,
> >> I'm encountering a problem in my app where users are double submitting
> a
> >> form, creating a hibernate exception in the back end where two
> >> sessions are attempting to update the same collection. I've read some
> >> posts about preventing form resubmission by using a unique token in the
> >> form to detect a double submit.
> >>
> >> If a double submit is detected, the second and subsequent submits wait
> >> until the original one returns and then report the outcome of that
> >> transaction (if I understand correctly, it's the last submit that
> issues
> >> the response to the user, and the first one does the updating).
> >>
> >> I'm wondering
> >> a) is this indeed the right approach to stop users who are
> >> over-enthusiastic in their button clicking from encountering errors,
> and
> >> b) does anyone have an actual example of code that implements this
> >> pattern?
> >> Thanks very much
> >> Denis Mc.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: preventing double submit in tapestry
Posted by Denis McCarthy <dm...@annadaletech.com>.
I was looking for a sledgehammer to crack a nut. That's how I ended up
doing it (after spending the day looking for an enterprisey solution!)
Thanks
Denis
Jesse Kuhnert wrote:
> Why don't you just disable the submit buttons in question when they submit?
> (set the disabled attribute to true)
>
> On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
>>
>> Hi,
>> I'm encountering a problem in my app where users are double submitting a
>> form, creating a hibernate exception in the back end where two
>> sessions are attempting to update the same collection. I've read some
>> posts about preventing form resubmission by using a unique token in the
>> form to detect a double submit.
>>
>> If a double submit is detected, the second and subsequent submits wait
>> until the original one returns and then report the outcome of that
>> transaction (if I understand correctly, it's the last submit that issues
>> the response to the user, and the first one does the updating).
>>
>> I'm wondering
>> a) is this indeed the right approach to stop users who are
>> over-enthusiastic in their button clicking from encountering errors, and
>> b) does anyone have an actual example of code that implements this
>> pattern?
>> Thanks very much
>> Denis Mc.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: preventing double submit in tapestry
Posted by Jesse Kuhnert <jk...@gmail.com>.
Why don't you just disable the submit buttons in question when they submit?
(set the disabled attribute to true)
On 11/15/06, Denis McCarthy <dm...@annadaletech.com> wrote:
>
> Hi,
> I'm encountering a problem in my app where users are double submitting a
> form, creating a hibernate exception in the back end where two
> sessions are attempting to update the same collection. I've read some
> posts about preventing form resubmission by using a unique token in the
> form to detect a double submit.
>
> If a double submit is detected, the second and subsequent submits wait
> until the original one returns and then report the outcome of that
> transaction (if I understand correctly, it's the last submit that issues
> the response to the user, and the first one does the updating).
>
> I'm wondering
> a) is this indeed the right approach to stop users who are
> over-enthusiastic in their button clicking from encountering errors, and
> b) does anyone have an actual example of code that implements this
> pattern?
> Thanks very much
> Denis Mc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
preventing double submit in tapestry
Posted by Denis McCarthy <dm...@annadaletech.com>.
Hi,
I'm encountering a problem in my app where users are double submitting a
form, creating a hibernate exception in the back end where two
sessions are attempting to update the same collection. I've read some
posts about preventing form resubmission by using a unique token in the
form to detect a double submit.
If a double submit is detected, the second and subsequent submits wait
until the original one returns and then report the outcome of that
transaction (if I understand correctly, it's the last submit that issues
the response to the user, and the first one does the updating).
I'm wondering
a) is this indeed the right approach to stop users who are
over-enthusiastic in their button clicking from encountering errors, and
b) does anyone have an actual example of code that implements this pattern?
Thanks very much
Denis Mc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org