[ic] Back Button Interaction with IC

[Ron Phipps]

> From: interchange-users-admin@interchange.redhat.com
[mailto:interchange-
> users-admin@interchange.redhat.com] On Behalf Of Ed LaFrance
> 
> At 02:28 PM 4/15/2002 -0700, you wrote:
> >Hello,
> >
> >We are using the [button] tags to generate the checkout, recalculate,
> >clear basket, continue shopping etc buttons like in the foundation
demo.
> >We've found that users have been able to checkout without actually
> >pushing the checkout button on the checkout.html page.  How they are
> >doing this is they place an item in their cart, which then forwards
them
> >to the basket page.  They then click on the go to checkout button
which
> >forwards them to the checkout page.  They are then able to push the
back
> >button on their browser (which puts them back on the basket page) and
> >push the recalculate, clear basket, or go to checkout button and
their
> >order is placed without going through the normal checkout_profile
> >routines for validation.  This also allows them to checkout without
> >selecting a payment method or valid shipping since they never make it
to
> >checkout_profile.  If the user then clicks the back button again and
> >they are returned to the basket page and can again push recalculate,
> >clear basket or go to checkout and the order will be placed with no
> >items in the cart and no validation once again.
> >
> >Has anyone else experienced this?  And if so what did you do to fix
the
> >problem?  Our client is seeing this in about 1/3 of the orders so it
> >looks like the practice is not abnormal to use the back buttons for
> >navigation.  I'll be looking into fixes this afternoon and will pass
> >along what I find.  I'll also be trying this out on the demo site to
see
> >if the same thing happens.  Thanks!
> >
> >-Ron
> 
> You must have customized the foundation catalog, because this didn't
> happen
> to me on the unmodified demo.

You are %100 correct.  After I sent that message I went to the demo site
and could not reproduce the problem there so I went back to the drawing
board and compared the layout of my ITL to the foundation ITL.  Here's
what I found.

I had the following button code on the basket page:

		[button
			text="Continue shopping"
     			src="buttons/b_cont_shopping.gif"
			hidetext=1
			form=basket
		]
     			[bounce page=index]
    			mv_nextpage=nothing
    		[/button]
		[button
			text="Clear Basket"
     			src="buttons/b_clear_basket.gif"
			hidetext=1
			form=basket
		]
			mv_todo=cancel
			mv_nextpage=index
		[/button]
		[button
			text="Recalculate"
     			src="buttons/b_recalc.gif"
			hidetext=1
			form=basket
		]
			mv_todo=return
			mv_nextpage=ord/basket
		[/button]

		[button
			text="Checkout"
     			src="buttons/b_checkout.gif"
			hidetext=1
			form=basket
		]
			mv_todo=return
			mv_nextpage=ord/checkout
		[/button]

I then had the following button code on the checkout page:

	[if items]
		[button
			text="Checkout"
     			src="buttons/b_checkout.gif"
			hidetext=1
			form=checkout
		]
			mv_todo=submit	
		[/button]
	[else]
		 
	[/else]
	[/if]

Please notice that the checkout button on the basket page means "go to
checkout page" and the checkout button on the checkout page means
"complete order"

Now the scenario was that as long as I went to the checkout page first
and did not try to submit the page I could then use the back buttons and
push the recalculate, clear basket, or checkout buttons and the order
would be placed without going through checkout_profile.  I could then
backup from the receipt page and do it over and over and the order would
be placed without line items or shipping.

I began to look at the basket checkout button and compared the code to
other stores I have that work correctly and noticed that the text was
the same between the basket page and the checkout page.  I remember back
before we had the button tag that text matching was done to know which
piece of ITL code to run when the button was pushed.  So I thought that
maybe the button code was cached for the checkout page and that's what
was running on the basket page.  Sure enough I changed the text of the
button on the basket page to read "Go To Checkout" and retested the
scenario and it no longer could be produced.  I could not place the
order with the go to checkout, recalculate or clear basket buttons as I
could before.

Now the thing I still have not figured out is why the other buttons on
the basket page were able to place the order even though they did not
have the same text parameter in the button tag.  Perhaps because there
was one text parameter that matched all of them gained the behavior of
the matching button.

I also think the checkout_profile was not being ran because the hidden
mv_order_profile html object was never submitted on the checkout page so
when IC was told to place the order it was able to do so without running
a profile.

I plan to look into this some more once I bring the development catalog
up in a few weeks.

> The only time I had a similar problem was
> with a customized catalog in which I had created two order profiles
with
> the same but different contents. I don't remember the exact
circumstances,
> but through a particular sequence of events which incorporated the use
of
> the browser 'Back' button, the customer was able to load one of the
> profiles into the session, and then inevitably use it in place of the
> other
> one; the net result was that the order checks were bypassed.  Since
then I
> have always been careful to ensure that every profile have a unique
name!
> 
> - Ed L.

I verified that the profile names are in fact different but it looks
like we both got bit by a similar situation; duplicate text (in your
case the profile, in my case the button) allowed the user to do
something we did not want them to do.  Thanks for your insight!

-Ron