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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security
Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
