Check out success continue

[aussieguy]

Hi

When a customer completes the checkout process they are given this page checkout_success.php which has a CONTINUE button on it

 

When the customer clicks the continue button they get a 404 page not found error message

They get this message whether or not the receive email updates "radio button" is selected.

 

I have checked the URL it appears to be correct.

The URL in the source is identical to the one that appears in the address bar before you click the continue button...

 

I believe the continue button goes back to the checkout_success.php so that the customers input from the recieve e-mail notification is updated then I would assume that the customer is redirected to another page?

 

 

 

any Ideas would be appreciated

 

store is located at

http://anoriginalkalakaua.com/catalog/

 

you can do a dummy order if you like, but make sure that you state it is a TEST order, the store is live and the order goes to the owner of the site...

 

Thankyou

[♥Vger]

The only thing that strikes me is when people click the link from your main homepage to come to the osCommerce site the link is set as index.php?cPath=21 - which is not necessary - it just needs to be to index.php. This may be messing up your session info.

 

The customer, when they click the Continue button at the end of the purchase should go back to index.php

 

Vger

[imagixx]

Same problem, on a shared SSL server. Have found no solution yet.

 

Anyone?

[imagixx]

Found this bug in a shared SSL server environment. Followed urchin.nl's May 26, 2004 suggestion for modification of general.php at:

 

http://www.oscommerce.com/forums/index.php?showtopic=74717&st=10

 

And it worked fine, redirecting to the start page.

 

Good work, urchin.nl!!!

 

I'm not much at this, but this change works - so I would suggest that you consider this change on releases.

 

This Bug Reported at: http://www.oscommerce.com/community/bugs,1429

 

Marty

[stevel]

First of all, this problem occurs only when using hosts that require you to separate SSL and non-SSL content, and occurs when you don't duplicate all your site files in both areas. I never understood why some hosts do this - mine doesn't - there's no good reason for it.

 

The "fix" isn't a fix - it's a workaround for a store configuration error. If you had duplicated all your store's files to both areas, this problem would not occur. The side-effect of the change is that some browsers will issue a warning when the customer clicks Continue about being redirected to a non-secure page. The code in tep_redirect is there for a reason.

 

The bug you pointed to is unrelated to the behavior you encountered.

[imagixx]

Hello Steve,

 

All I know is that, after review of many posts on the same issue, the problem seems to occur when a shared SSL certificate is used. For example:

 

http://www.mydomain.com

 

and https://secure-server.com/mydomain.com

 

After a successful checkout (which always occurs in secure mode), apparently, the Continue wants to put you back into the non-secure start page. But, the file structure is not the same. The "work around" merely redirects you to the secure start page. From there, any product link takes you back to the non-secure site.

 

I think that [email protected] stated the problem clearly:

 

"Also found out that redirect-script wrongly assumes catalog-directory for HTTP and HTTPS are the same. I created an almost identical solution to the one mentioned below (unable to find any solution with this !@#$^% forum-search: no offence guys) and put it here" and included the reference indicated in my previous post.

 

So, if that wasn't "my problem" - what was it? If that isn't a "bug" for those using a shared SSL certificate, is it a misconfiguration? All I know is that the symptoms existed, and the work "around" fixed it.

 

Regards,

 

Martin

[stevel]

My apologies - there are so many cases where it's just a configuration error that I missed what was being fixed here. You are correct - tep_redirect does have a bug which is fixed by the change you linked to. This is a problem only on sites where DIR_WS_HTTPS_CATALOG is different from DIR_WS_HTTP_CATALOG.