You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Erik Weber <er...@mindspring.com> on 2004/08/25 15:03:18 UTC
Problem with saveToken(HttpServletRequest)
I am using saveToken, isTokenValid, etc., to ensure that a
registration/update form is not stale. I invoke this method from execute
in the setup Action, just before forwarding to the form page.
When the form is submitted, there are two levels of validation before
the form data is processed.
First, input validation happens. I use ValidatorForm with the Validator
plugin. If there is an input validation error, Struts forwards back to
the input page, and the original synchronizer token is still in place as
a hidden variable in the form.
Second, if input validation succeeds, there is validation at the manager
layer. For example, a username might already be taken. If there is a
manager validation error, Struts forwards back to the input page, but
this time, the synchronizer token is not in place -- the hidden field in
the form is gone.
The result of this is that if you request an add/edit form, fill it out,
submit it and cause a manager validation error, you cannot simply edit
the offending field and resubmit the form -- you need a fresh form. This
is not the desired behavior, as this type of validation error should be
treated the same as a form validation error, with regard to the
synchronizer token.
I am using Struts declarative exception handling, which handles the
forwarding.
How can I make sure the hidden field is rendered in the form after the
second type of error occurs and Struts forwards back to the input
screen? Why is it gone in the first place? I thought of
RequestProcessor.processException, but couldn't see a way to invoke
resetToken or saveToken. Should I do something with my form bean reset
method?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Bill Siggelkow <bi...@bellsouth.net>.
NP - by the way, if you do end up wanting to look at a custom
ExceptionHandler is really pretty easy -- about as easy as writing an
Action!
Bill Siggelkow
Erik Weber wrote:
> And thanks for posting in the first place, or I might not have figured
> this out.
>
> Erik
>
>
> Erik Weber wrote:
>
>> Bill, sorry, I found the problem. I was invoking resetToken after
>> making sure the form was valid, but before one of these
>> declaratively-handled exceptions was being thrown, in my "save"
>> action. I put the resetToken invocation right after the isTokenValid
>> invocation, out of habit. But resetToken doesn't belong there. It
>> should be the last thing done in the execute method.
>>
>> Hope I didn't waste too much of your time.
>>
>> Erik
>>
>>
>> Erik Weber wrote:
>>
>>> Yes, my "input" attribute is set to the JSP I came from. Also I tried
>>> with and without the "path" attribute to the exception element
>>> itself. No luck.
>>>
>>> I am using 1.1. I wonder if this is the problem.
>>>
>>> Where would the token field get "whacked" from? Whose field is it?
>>> There is nothing required of the form bean or the JSP itself to make
>>> this work, right?
>>>
>>> Sheesh, I wonder if I should just implement my own synchronizer
>>> token. I can't upgrade to 1.2.
>>>
>>> Thanks,
>>> Erik
>>>
>>>
>>> Bill Siggelkow wrote:
>>>
>>>> Erik Weber wrote:
>>>>
>>>>> Bill, my login action is almost identical to yours up until the
>>>>> forward element, but I *am* losing the token. You said you thought
>>>>> this might happen if I redirected back to the login page instead of
>>>>> forwarding, but I don't even know how I would do that . . .
>>>>>
>>>>> What version of Struts are you using?
>>>>>
>>>>> Erik
>>>>>
>>>> I am using Struts 1.2; I haven't tested this in 1.1 yet. Is your
>>>> input attribute set to the JSP you came from? It could be redirected
>>>> if you were specifying a path for the local exception that resulted
>>>> in a redirect. If you are not specifying a path than the default
>>>> exception handler uses:
>>>>
>>>> ActionForward forward = mapping.getInputForward();
>>>>
>>>> If you get stuck I would debug the puppy -- simply set a breakpoint
>>>> in the ExceptionHandler's execute method and see if the token field
>>>> is getting whacked.
>>>>
>>>> Bill Siggelkow
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Erik Weber <er...@mindspring.com>.
And thanks for posting in the first place, or I might not have figured
this out.
Erik
Erik Weber wrote:
> Bill, sorry, I found the problem. I was invoking resetToken after
> making sure the form was valid, but before one of these
> declaratively-handled exceptions was being thrown, in my "save"
> action. I put the resetToken invocation right after the isTokenValid
> invocation, out of habit. But resetToken doesn't belong there. It
> should be the last thing done in the execute method.
>
> Hope I didn't waste too much of your time.
>
> Erik
>
>
> Erik Weber wrote:
>
>> Yes, my "input" attribute is set to the JSP I came from. Also I tried
>> with and without the "path" attribute to the exception element
>> itself. No luck.
>>
>> I am using 1.1. I wonder if this is the problem.
>>
>> Where would the token field get "whacked" from? Whose field is it?
>> There is nothing required of the form bean or the JSP itself to make
>> this work, right?
>>
>> Sheesh, I wonder if I should just implement my own synchronizer
>> token. I can't upgrade to 1.2.
>>
>> Thanks,
>> Erik
>>
>>
>> Bill Siggelkow wrote:
>>
>>> Erik Weber wrote:
>>>
>>>> Bill, my login action is almost identical to yours up until the
>>>> forward element, but I *am* losing the token. You said you thought
>>>> this might happen if I redirected back to the login page instead of
>>>> forwarding, but I don't even know how I would do that . . .
>>>>
>>>> What version of Struts are you using?
>>>>
>>>> Erik
>>>>
>>> I am using Struts 1.2; I haven't tested this in 1.1 yet. Is your
>>> input attribute set to the JSP you came from? It could be redirected
>>> if you were specifying a path for the local exception that resulted
>>> in a redirect. If you are not specifying a path than the default
>>> exception handler uses:
>>>
>>> ActionForward forward = mapping.getInputForward();
>>>
>>> If you get stuck I would debug the puppy -- simply set a breakpoint
>>> in the ExceptionHandler's execute method and see if the token field
>>> is getting whacked.
>>>
>>> Bill Siggelkow
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Erik Weber <er...@mindspring.com>.
Bill, sorry, I found the problem. I was invoking resetToken after making
sure the form was valid, but before one of these declaratively-handled
exceptions was being thrown, in my "save" action. I put the resetToken
invocation right after the isTokenValid invocation, out of habit. But
resetToken doesn't belong there. It should be the last thing done in the
execute method.
Hope I didn't waste too much of your time.
Erik
Erik Weber wrote:
> Yes, my "input" attribute is set to the JSP I came from. Also I tried
> with and without the "path" attribute to the exception element itself.
> No luck.
>
> I am using 1.1. I wonder if this is the problem.
>
> Where would the token field get "whacked" from? Whose field is it?
> There is nothing required of the form bean or the JSP itself to make
> this work, right?
>
> Sheesh, I wonder if I should just implement my own synchronizer token.
> I can't upgrade to 1.2.
>
> Thanks,
> Erik
>
>
> Bill Siggelkow wrote:
>
>> Erik Weber wrote:
>>
>>> Bill, my login action is almost identical to yours up until the
>>> forward element, but I *am* losing the token. You said you thought
>>> this might happen if I redirected back to the login page instead of
>>> forwarding, but I don't even know how I would do that . . .
>>>
>>> What version of Struts are you using?
>>>
>>> Erik
>>>
>> I am using Struts 1.2; I haven't tested this in 1.1 yet. Is your
>> input attribute set to the JSP you came from? It could be redirected
>> if you were specifying a path for the local exception that resulted
>> in a redirect. If you are not specifying a path than the default
>> exception handler uses:
>>
>> ActionForward forward = mapping.getInputForward();
>>
>> If you get stuck I would debug the puppy -- simply set a breakpoint
>> in the ExceptionHandler's execute method and see if the token field
>> is getting whacked.
>>
>> Bill Siggelkow
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Erik Weber <er...@mindspring.com>.
Yes, my "input" attribute is set to the JSP I came from. Also I tried
with and without the "path" attribute to the exception element itself.
No luck.
I am using 1.1. I wonder if this is the problem.
Where would the token field get "whacked" from? Whose field is it? There
is nothing required of the form bean or the JSP itself to make this
work, right?
Sheesh, I wonder if I should just implement my own synchronizer token. I
can't upgrade to 1.2.
Thanks,
Erik
Bill Siggelkow wrote:
> Erik Weber wrote:
>
>> Bill, my login action is almost identical to yours up until the
>> forward element, but I *am* losing the token. You said you thought
>> this might happen if I redirected back to the login page instead of
>> forwarding, but I don't even know how I would do that . . .
>>
>> What version of Struts are you using?
>>
>> Erik
>>
> I am using Struts 1.2; I haven't tested this in 1.1 yet. Is your input
> attribute set to the JSP you came from? It could be redirected if you
> were specifying a path for the local exception that resulted in a
> redirect. If you are not specifying a path than the default exception
> handler uses:
>
> ActionForward forward = mapping.getInputForward();
>
> If you get stuck I would debug the puppy -- simply set a breakpoint in
> the ExceptionHandler's execute method and see if the token field is
> getting whacked.
>
> Bill Siggelkow
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts 1.2
Posted by David Durham <da...@scott.af.mil>.
Bill Siggelkow wrote:
> Try here -- though 1.2.2 should be about the same as the nightly me
> thinks.
Nah. These struts committers kick out shoddy nightly effluvia.
:-D
> http://cvs.apache.org/dist/struts/
Thanks.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts 1.2
Posted by Bill Siggelkow <bi...@bellsouth.net>.
Try here -- though 1.2.2 should be about the same as the nightly me thinks.
http://cvs.apache.org/dist/struts/
David Durham wrote:
> Bill Siggelkow wrote:
>
>> I am using Struts 1.2;
>
>
> Where do you download 1.2?
>
> Is it just a nightly build available here:
>
> http://cvs.apache.org/builds/jakarta-struts/nightly/
>
> Thanks,
>
> - Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts 1.2
Posted by Ted Husted <hu...@apache.org>.
Struts 1.2.1 is available here:
http://struts.apache.org/acquiring.html
and, yes, Struts 1.2.2 will be the latest nightly build for the day we roll it. (Looks like today!)
-Ted.
On Wed, 25 Aug 2004 15:41:10 -0500, David Durham wrote:
>�Bill Siggelkow wrote:
>
>>�I am using Struts 1.2;
>>
>�Where do you download 1.2?
>
>�Is it just a nightly build available here:
>
>�http://cvs.apache.org/builds/jakarta-struts/nightly/
>
>�Thanks,
>
>�- Dave
>
>�--------------------------------------------------------------------
>�- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For
>�additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts 1.2
Posted by David Durham <da...@scott.af.mil>.
Bill Siggelkow wrote:
> I am using Struts 1.2;
Where do you download 1.2?
Is it just a nightly build available here:
http://cvs.apache.org/builds/jakarta-struts/nightly/
Thanks,
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Bill Siggelkow <bi...@bellsouth.net>.
Erik Weber wrote:
> Bill, my login action is almost identical to yours up until the forward
> element, but I *am* losing the token. You said you thought this might
> happen if I redirected back to the login page instead of forwarding, but
> I don't even know how I would do that . . .
>
> What version of Struts are you using?
>
> Erik
>
I am using Struts 1.2; I haven't tested this in 1.1 yet. Is your input
attribute set to the JSP you came from? It could be redirected if you
were specifying a path for the local exception that resulted in a
redirect. If you are not specifying a path than the default exception
handler uses:
ActionForward forward = mapping.getInputForward();
If you get stuck I would debug the puppy -- simply set a breakpoint in
the ExceptionHandler's execute method and see if the token field is
getting whacked.
Bill Siggelkow
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Erik Weber <er...@mindspring.com>.
Bill, my login action is almost identical to yours up until the forward
element, but I *am* losing the token. You said you thought this might
happen if I redirected back to the login page instead of forwarding, but
I don't even know how I would do that . . .
What version of Struts are you using?
Erik
Bill Siggelkow wrote:
> Erik,
>
> I just tried an example of what you are saying (triggering a
> declarative exception and then losing the token in the redisplayed
> form) and I did not lose the token! Here is the action mapping I am
> using:
>
> <action path="/Login"
> type="com.oreilly.strutsckbk.ch09.LoginAction"
> scope="request"
> name="LoginForm"
> validate="true"
> input="/login.jsp">
> <exception key="error.password.match"
>
> type="com.oreilly.strutsckbk.ch09.PasswordMatchException"/>
> <forward name="success" path="/login_success.jsp" redirect="true"/>
> </action>
>
> The only reason I would think that the token would be lost would be if
> you redirected instead of forwarded to the input page.
>
> Bill Siggelkow
>
> Erik Weber wrote:
>
>> Susan, I could not use your option, but it did lead me to a solution.
>> I would like to know if anyone has a better solution, since mine
>> involves catching and rethrowing an Exception, which is, however
>> small, a performance hit to take. Also, it kind of defeats the
>> purpose of Struts' declarative Exception handling. I have a specific
>> question for those who might be more familiar with Struts code (I
>> have successfully avoided fooling with the source code so far).
>>
>> Since my "validation" error is really an Exception that is thrown by
>> a manager layer object and that is handled by the Struts Exception
>> handler according to what is configured in struts-config.xml, I
>> didn't have a place to invoke saveToken if one of these Exceptions
>> was thrown, because my Action was not catching the Exception --
>> Struts' Exception handler was.
>>
>> So I put in a try-catch block in my Action code around the
>> invocations to the manager layer objects. If one of these
>> "validation" Exceptions is thrown, I catch it and simply rethrow it
>> -- but this gives me a place to insert a saveToken invocation before
>> I rethrow the Exception. It's not ideal, but it's simple at least.
>>
>> What I really would like is, to mimic what Action.saveToken does,
>> within the execute method of an ExceptionHandler extension, whenever
>> one of these types of Exceptions is handled. Then I don't have to
>> catch and rethrow. Will this work? It might depend on what exactly
>> Action.saveToken is doing (and how the token hidden parameter ends up
>> being rendered in the form) I guess, since the invocation of
>> saveToken would occur in a different chronological place
>> (ExceptionHandler.execute) from where it occurs in my current
>> solution (Action.execute).
>>
>> Or is there a better idea still?
>>
>> Thanks,
>> Erik
>>
>>
>>
>> Susan Bradeen wrote:
>>
>>> Erik Weber <er...@mindspring.com> wrote on 08/25/2004 09:03:18 AM:
>>>
>>>
>>>
>>>> I am using saveToken, isTokenValid, etc., to ensure that a
>>>> registration/update form is not stale. I invoke this method from
>>>> execute
>>>
>>>
>>>
>>>
>>>
>>>> in the setup Action, just before forwarding to the form page.
>>>>
>>>> When the form is submitted, there are two levels of validation
>>>> before the form data is processed.
>>>>
>>>> First, input validation happens. I use ValidatorForm with the
>>>> Validator plugin. If there is an input validation error, Struts
>>>> forwards back to the input page, and the original synchronizer
>>>> token is still in place as
>>>
>>>
>>>
>>>
>>>
>>>> a hidden variable in the form.
>>>>
>>>> Second, if input validation succeeds, there is validation at the
>>>> manager
>>>
>>>
>>>
>>>
>>>
>>>> layer. For example, a username might already be taken. If there is
>>>> a manager validation error, Struts forwards back to the input page,
>>>> but this time, the synchronizer token is not in place -- the hidden
>>>> field in
>>>
>>>
>>>
>>>
>>>
>>>> the form is gone.
>>>
>>>
>>>
>>> Erik, You are probably doing validation differently, but maybe this
>>> will spur some ideas. I called the validate from the 'save' Action,
>>> and passed the token with the request again after it failed validation:
>>>
>>> if (!isCancelled(request)) {
>>>
>>> // Validate form parameters ... ActionErrors validErrors =
>>> reqForm.validate(mapping, request);
>>> if (validErrors != null && !validErrors.isEmpty()) {
>>> saveErrors(request, validErrors);
>>> saveToken(request);
>>> return new ActionForward(mapping.getInput());
>>> }// end validate
>>>
>>> ...}
>>>
>>> HTH,
>>> Susan Bradeen
>>>
>>>> The result of this is that if you request an add/edit form, fill it
>>>> out,
>>>
>>>
>>>
>>>
>>>
>>>> submit it and cause a manager validation error, you cannot simply
>>>> edit the offending field and resubmit the form -- you need a fresh
>>>> form. This
>>>
>>>
>>>
>>>
>>>
>>>> is not the desired behavior, as this type of validation error
>>>> should be treated the same as a form validation error, with regard
>>>> to the synchronizer token.
>>>>
>>>> I am using Struts declarative exception handling, which handles the
>>>> forwarding.
>>>>
>>>> How can I make sure the hidden field is rendered in the form after
>>>> the second type of error occurs and Struts forwards back to the
>>>> input screen? Why is it gone in the first place? I thought of
>>>> RequestProcessor.processException, but couldn't see a way to invoke
>>>> resetToken or saveToken. Should I do something with my form bean
>>>> reset method?
>>>>
>>>> Erik
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>
>>>
>>> _____________________________________________________________________________
>>>
>>> Scanned for SoftLanding Systems, Inc. by IBM Email Security
>>> Management Services powered by MessageLabs.
>>> _____________________________________________________________________________
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Bill Siggelkow <bi...@bellsouth.net>.
Erik,
I just tried an example of what you are saying (triggering a declarative
exception and then losing the token in the redisplayed form) and I did
not lose the token! Here is the action mapping I am using:
<action path="/Login"
type="com.oreilly.strutsckbk.ch09.LoginAction"
scope="request"
name="LoginForm"
validate="true"
input="/login.jsp">
<exception key="error.password.match"
type="com.oreilly.strutsckbk.ch09.PasswordMatchException"/>
<forward name="success" path="/login_success.jsp" redirect="true"/>
</action>
The only reason I would think that the token would be lost would be if
you redirected instead of forwarded to the input page.
Bill Siggelkow
Erik Weber wrote:
> Susan, I could not use your option, but it did lead me to a solution. I
> would like to know if anyone has a better solution, since mine involves
> catching and rethrowing an Exception, which is, however small, a
> performance hit to take. Also, it kind of defeats the purpose of Struts'
> declarative Exception handling. I have a specific question for those who
> might be more familiar with Struts code (I have successfully avoided
> fooling with the source code so far).
>
> Since my "validation" error is really an Exception that is thrown by a
> manager layer object and that is handled by the Struts Exception handler
> according to what is configured in struts-config.xml, I didn't have a
> place to invoke saveToken if one of these Exceptions was thrown, because
> my Action was not catching the Exception -- Struts' Exception handler was.
>
> So I put in a try-catch block in my Action code around the invocations
> to the manager layer objects. If one of these "validation" Exceptions is
> thrown, I catch it and simply rethrow it -- but this gives me a place to
> insert a saveToken invocation before I rethrow the Exception. It's not
> ideal, but it's simple at least.
>
> What I really would like is, to mimic what Action.saveToken does, within
> the execute method of an ExceptionHandler extension, whenever one of
> these types of Exceptions is handled. Then I don't have to catch and
> rethrow. Will this work? It might depend on what exactly
> Action.saveToken is doing (and how the token hidden parameter ends up
> being rendered in the form) I guess, since the invocation of saveToken
> would occur in a different chronological place
> (ExceptionHandler.execute) from where it occurs in my current solution
> (Action.execute).
>
> Or is there a better idea still?
>
> Thanks,
> Erik
>
>
>
> Susan Bradeen wrote:
>
>> Erik Weber <er...@mindspring.com> wrote on 08/25/2004 09:03:18 AM:
>>
>>
>>
>>> I am using saveToken, isTokenValid, etc., to ensure that a
>>> registration/update form is not stale. I invoke this method from
>>> execute
>>
>>
>>
>>
>>> in the setup Action, just before forwarding to the form page.
>>>
>>> When the form is submitted, there are two levels of validation before
>>> the form data is processed.
>>>
>>> First, input validation happens. I use ValidatorForm with the
>>> Validator plugin. If there is an input validation error, Struts
>>> forwards back to the input page, and the original synchronizer token
>>> is still in place as
>>
>>
>>
>>
>>> a hidden variable in the form.
>>>
>>> Second, if input validation succeeds, there is validation at the
>>> manager
>>
>>
>>
>>
>>> layer. For example, a username might already be taken. If there is a
>>> manager validation error, Struts forwards back to the input page, but
>>> this time, the synchronizer token is not in place -- the hidden field
>>> in
>>
>>
>>
>>
>>> the form is gone.
>>>
>>
>>
>> Erik, You are probably doing validation differently, but maybe this
>> will spur some ideas. I called the validate from the 'save' Action,
>> and passed the token with the request again after it failed validation:
>>
>> if (!isCancelled(request)) {
>>
>> // Validate form parameters ... ActionErrors validErrors =
>> reqForm.validate(mapping, request);
>> if (validErrors != null && !validErrors.isEmpty()) {
>> saveErrors(request, validErrors);
>> saveToken(request);
>> return new ActionForward(mapping.getInput());
>> }// end validate
>>
>> ...}
>>
>> HTH,
>> Susan Bradeen
>>
>>
>>> The result of this is that if you request an add/edit form, fill it
>>> out,
>>
>>
>>
>>
>>> submit it and cause a manager validation error, you cannot simply
>>> edit the offending field and resubmit the form -- you need a fresh
>>> form. This
>>
>>
>>
>>
>>> is not the desired behavior, as this type of validation error should
>>> be treated the same as a form validation error, with regard to the
>>> synchronizer token.
>>>
>>> I am using Struts declarative exception handling, which handles the
>>> forwarding.
>>>
>>> How can I make sure the hidden field is rendered in the form after
>>> the second type of error occurs and Struts forwards back to the input
>>> screen? Why is it gone in the first place? I thought of
>>> RequestProcessor.processException, but couldn't see a way to invoke
>>> resetToken or saveToken. Should I do something with my form bean
>>> reset method?
>>>
>>> Erik
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>> _____________________________________________________________________________
>>
>> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
>> Services powered by MessageLabs.
>> _____________________________________________________________________________
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Erik Weber <er...@mindspring.com>.
Susan, I could not use your option, but it did lead me to a solution. I
would like to know if anyone has a better solution, since mine involves
catching and rethrowing an Exception, which is, however small, a
performance hit to take. Also, it kind of defeats the purpose of Struts'
declarative Exception handling. I have a specific question for those who
might be more familiar with Struts code (I have successfully avoided
fooling with the source code so far).
Since my "validation" error is really an Exception that is thrown by a
manager layer object and that is handled by the Struts Exception handler
according to what is configured in struts-config.xml, I didn't have a
place to invoke saveToken if one of these Exceptions was thrown, because
my Action was not catching the Exception -- Struts' Exception handler was.
So I put in a try-catch block in my Action code around the invocations
to the manager layer objects. If one of these "validation" Exceptions is
thrown, I catch it and simply rethrow it -- but this gives me a place to
insert a saveToken invocation before I rethrow the Exception. It's not
ideal, but it's simple at least.
What I really would like is, to mimic what Action.saveToken does, within
the execute method of an ExceptionHandler extension, whenever one of
these types of Exceptions is handled. Then I don't have to catch and
rethrow. Will this work? It might depend on what exactly
Action.saveToken is doing (and how the token hidden parameter ends up
being rendered in the form) I guess, since the invocation of saveToken
would occur in a different chronological place
(ExceptionHandler.execute) from where it occurs in my current solution
(Action.execute).
Or is there a better idea still?
Thanks,
Erik
Susan Bradeen wrote:
>Erik Weber <er...@mindspring.com> wrote on 08/25/2004 09:03:18 AM:
>
>
>
>>I am using saveToken, isTokenValid, etc., to ensure that a
>>registration/update form is not stale. I invoke this method from execute
>>
>>
>
>
>
>>in the setup Action, just before forwarding to the form page.
>>
>>When the form is submitted, there are two levels of validation before
>>the form data is processed.
>>
>>First, input validation happens. I use ValidatorForm with the Validator
>>plugin. If there is an input validation error, Struts forwards back to
>>the input page, and the original synchronizer token is still in place as
>>
>>
>
>
>
>>a hidden variable in the form.
>>
>>Second, if input validation succeeds, there is validation at the manager
>>
>>
>
>
>
>>layer. For example, a username might already be taken. If there is a
>>manager validation error, Struts forwards back to the input page, but
>>this time, the synchronizer token is not in place -- the hidden field in
>>
>>
>
>
>
>>the form is gone.
>>
>>
>
>Erik,
>You are probably doing validation differently, but maybe this will spur
>some ideas. I called the validate from the 'save' Action, and passed the
>token with the request again after it failed validation:
>
>if (!isCancelled(request)) {
>
> // Validate form parameters ...
> ActionErrors validErrors = reqForm.validate(mapping, request);
> if (validErrors != null && !validErrors.isEmpty()) {
> saveErrors(request, validErrors);
> saveToken(request);
> return new ActionForward(mapping.getInput());
> }// end validate
>
>...}
>
>HTH,
>Susan Bradeen
>
>
>
>>The result of this is that if you request an add/edit form, fill it out,
>>
>>
>
>
>
>>submit it and cause a manager validation error, you cannot simply edit
>>the offending field and resubmit the form -- you need a fresh form. This
>>
>>
>
>
>
>>is not the desired behavior, as this type of validation error should be
>>treated the same as a form validation error, with regard to the
>>synchronizer token.
>>
>>I am using Struts declarative exception handling, which handles the
>>forwarding.
>>
>>How can I make sure the hidden field is rendered in the form after the
>>second type of error occurs and Struts forwards back to the input
>>screen? Why is it gone in the first place? I thought of
>>RequestProcessor.processException, but couldn't see a way to invoke
>>resetToken or saveToken. Should I do something with my form bean reset
>>method?
>>
>>Erik
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>_____________________________________________________________________________
>Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
>_____________________________________________________________________________
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem with saveToken(HttpServletRequest)
Posted by Susan Bradeen <Su...@softlanding.com>.
Erik Weber <er...@mindspring.com> wrote on 08/25/2004 09:03:18 AM:
> I am using saveToken, isTokenValid, etc., to ensure that a
> registration/update form is not stale. I invoke this method from execute
> in the setup Action, just before forwarding to the form page.
>
> When the form is submitted, there are two levels of validation before
> the form data is processed.
>
> First, input validation happens. I use ValidatorForm with the Validator
> plugin. If there is an input validation error, Struts forwards back to
> the input page, and the original synchronizer token is still in place as
> a hidden variable in the form.
>
> Second, if input validation succeeds, there is validation at the manager
> layer. For example, a username might already be taken. If there is a
> manager validation error, Struts forwards back to the input page, but
> this time, the synchronizer token is not in place -- the hidden field in
> the form is gone.
Erik,
You are probably doing validation differently, but maybe this will spur
some ideas. I called the validate from the 'save' Action, and passed the
token with the request again after it failed validation:
if (!isCancelled(request)) {
// Validate form parameters ...
ActionErrors validErrors = reqForm.validate(mapping, request);
if (validErrors != null && !validErrors.isEmpty()) {
saveErrors(request, validErrors);
saveToken(request);
return new ActionForward(mapping.getInput());
}// end validate
...}
HTH,
Susan Bradeen
>
> The result of this is that if you request an add/edit form, fill it out,
> submit it and cause a manager validation error, you cannot simply edit
> the offending field and resubmit the form -- you need a fresh form. This
> is not the desired behavior, as this type of validation error should be
> treated the same as a form validation error, with regard to the
> synchronizer token.
>
> I am using Struts declarative exception handling, which handles the
> forwarding.
>
> How can I make sure the hidden field is rendered in the form after the
> second type of error occurs and Struts forwards back to the input
> screen? Why is it gone in the first place? I thought of
> RequestProcessor.processException, but couldn't see a way to invoke
> resetToken or saveToken. Should I do something with my form bean reset
> method?
>
> Erik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org