On Fri, 21 Jan 2005 16:26:51 -0600, snekse <[EMAIL PROTECTED]> wrote:
> I have a Best Practices type question. Where should I send the user
> if isValidToken returns FALSE?
This is the sort of question you should be asking yourself or probably
your business analyst. What do you want to do when there is a "double
submit"? (The requirement depends on the application, scenario etc)
for eg:
1) Suppose you forgot your password and there is a "Send password
through email" button. You may click on it multiple times, but that
doesn't mean you want the email multiple times and you expect the
application to take you to a page saying "email sent successfully".
So, in this case you may send the user to the "password sent success"
page
2) In some scenario's it makes sense not to check for double submit.
for eg: Sending an email to your buddy. Yahoo Mail sends multiple
mails if you click multiple times on the Send. It makes sense because
the "Subject" or the "Body" might have been changed between two
"Submits"
3) When you are deleting a record, it makes sense to check for double
submit because you can stop the user right there if he tries to delete
one which has been already deleted from a previous request (the first
genuine request before double submit) instead of try-catching the DAO
thrown "NoRecordFoundException" and doing nothing
4) Forum posting. Makes sense to not double post the same message (It
can be so irritating to the fellow posters)
>
> Here is the flow we have for this application.
>
> 1. User searches for a profile
> 2. List of matching profiles is displayed
> 3. User clicks the EDIT link for the profile they want to update
> 4. Profile is displayed with a TOKEN embedded in a hidden form field
> 5. User hits Submit to update changes (possibly hitting it twice).
> 6. If isValidToken == TRUE, call resetToken(request) and
> the Action will Forward to:
> a) A confim page using redirect on SUCCESS
> b) Back to the form page with error msgs on FAILURE
>
> So where do I go if isValidToken != TRUE?
Personally I wouldn't want to check for double submit if the action is
going to do an "Update" similar to your case (Profile Update) for the
simple reason that the form could have been changed between two
submits (If the Update is taking 5 secs, let's say (for whatever
reason), the user has enough time to change his profile and do another
submit before the previous submit is completed. In this case, it's
better to save the latest changes by the user)
> I think part of the problem
> is I won't really know *why* the token was invalid.
The following is typically the logic used to prevent double submit
if(isTokenValid(request)){
resetToken(request);
// do your action
} else{
// double submit -- do something else
}
If the token is valid (valid == token that comes in the request
matches with the token in the session) then do normal business logic
and "resetToken" (which removes the token attribute from the session".
So, in the double submit case the token becomes invalid because of the
fact that the first time we would have removed the token from the
session (with "resetToken") and so this time isTokenValid() returns
false (token that comes in the request doesn't match with the one in
the session (no token in the session))
> Here's what I'd
> like to do. I'd like to basically store in the session the Token, the
> requested ActionMapping and the UID of the object being handled (in
> this case a profile_ID). Then if the isValidToken returns false, look
> in the session for the last *successful* token that matched the
> ActionMapping and profile_ID for this request and send them to the
> same result page. Does that make sense?
I wouldn't want to store the "ActionMapping" in the session because I
get the same "ActionMapping" to the execute method. Well one pitfall I
think will potentially happen is this [ User successfully updates a
profile with profile id : 150 (no double submit) and you show him a
success page saying "profile with profile id 150 is successfully
updated"
Next thing the user does, being in the same session, is that he tries
to update profile with profile id 151 (but clicking multiple times).
Now your application will show the user "profile with profile id 150
is successfully updated" instead of showing "profile with profile id
151 is successfully updated" (Also with the potential of ignoring the
user's latest changes)
> Has anyone tried this
> before? Any pitfalls you could foresee? Is this just a plain bad
> idea? Any feedback on this would be greatly appreciated.
>
> Thanks,
> -Derek
>
> [FROM A PREVIOUS POST]
> > if(!isTokenValid(request)){
> > //token vaildation failed so send to error page (or straight onto
> > success page if desired)
> > return mapping.findForward("failure");
> > }else{
> > resetToken(request);
> > // do some work as token is ok
> > return mapping.findForward("success");
> > }
>
> ---------------------------------------------------------------------
> 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]
