Strange behav. when checkout or logon

[molafish]

I've had a succesful 2.2ms2 copy up and running for quite some time.

 

Recently this has happened (or I've noticed it):

 

When user goes to log in, is redirected to a 404 hit

https://[mySslHost]/index.html?action=process&osCsid=[blahblahblah]

this is wrong, intuitively it should go to:

https://[mySslHost]/[~myUserName]/index.html?[etc...]

 

my config file is in perfect shape and all other areas of the site work well.

 

this line in [catalog level]\login.php is calling the redirect:

tep_redirect(tep_href_link(FILENAME_DEFAULT));

 

As a temporary fix I've written an additional tep_redirect_alt() function for general.php which adds the "/~userName/".

 

But this is strange behavior. Any ideas?

 

Also, if a user tries to checkout with no items in his/her cart, the same type error occurs, a misdirect is executed to a file missing the preceding user path.

 

I haven't pulled up checkout_shipping.php yet, but I'm sure it will have a reference to tep_redirect().

 

So, anybody every run into this?

[molafish]

oops, I meant "znap" in the title.

[♥Vger]

Despite

my config file is in perfect shape

this still looks like a misconfiguration to me. Some problems do not crop up until you try to follow the Login/Logout and Checkout process through from beginning to end. The redirect back to the index.php is there for when an error occurs, and is the default response to login or checkout errors in config. Hope this helps - Vger

[molafish]

Roger. Obviously something's wrong.

 

When I said perfect shape, that was being lazy for not saying that my DIR_WS_HTTP_CATALOG and DIR_WS_HTTPS_CATALOG defines are set right. As are the other pertinent constants.

 

After playing around with it, I've found that if a user clicks on checkout, or myaccount, and then is redirected to the login page, they will not get the 404 but will be allowed to open the checkout_shipping and account pages. It's only when a user tries to plain "log in" that the 404 happens. What boggles my mind is that all three methods (I believe) make calls to tep_redirect.

 

My workaround is in place and solid, but it only applies to this one error, I did a search for all calls to tep_redirect() in osCommerce, and got <b>188 hits in 60 files!</b>

 

Now I guess I should test all 60 pages for all their redirects to see if I need to change them to my alternate redirect funcation as well.

 

:P

[♥Vger]

Now I guess I should test all 60 pages for all their redirects to see if I need to change them to my alternate redirect funcation as well.

No the redirect is not the problem. You have a misconfiguration somewhere in your config files. Vger

[molafish]

you are thinking on target, that's what I thought too.

 

But I checked it. Here, I'll illuminate the situation a little more:

 

[Extracted from configure.php]::[Actual domain names changed]

 

  define('HTTP_SERVER', 'http://www.dontmesswithtexas.com');

  define('HTTPS_SERVER', 'https://host.texas.com');

  define('ENABLE_SSL', true); // secure webserver for checkout procedure?

  define('HTTP_COOKIE_DOMAIN', 'dontmesswithtexas.com');

  define('HTTPS_COOKIE_DOMAIN', 'host.texas.com');

  define('HTTP_COOKIE_PATH', '/');

  define('HTTPS_COOKIE_PATH', '/~thisUser/');

  define('DIR_WS_HTTP_CATALOG', '/');

  define('DIR_WS_HTTPS_CATALOG', '/~thisUser/');

 

  define('DIR_FS_CATALOG', '/home/thisUser/public_html/');

 

As far as I have tested, all other navigation redirects are valid, they all manage to glue the proper pieces together

(i.e. http://host.texas.com/~thisUser/index.php or whatever)

 

But only these two lines so far, in login.php and checkout_shipping.php result in a location of: http://host.texas.com/index.php (or checkout_shipping.php):

 

login.php

60:        if (sizeof($navigation->snapshot) > 0) {

61:          $origin_href = tep_href_link($navigation->snapshot['page'], tep_array_to_string($navigation->snapshot['get'], array(tep_session_name())), $navigation->snapshot['mode']);

62:          $navigation->clear_snapshot();

63:          tep_redirect($origin_href);

64:        } else {

65:          tep_redirect(tep_href_link(FILENAME_DEFAULT));

66:        }

 

Line 65 is the redirect call. And FILENAME_DEFAULT is "index.php"

 

checkout_shipping.php

22: // if there is nothing in the customers cart, redirect them to the shopping cart page

23:  if ($cart->count_contents() < 1) {

24:    tep_redirect(tep_href_link(FILENAME_SHOPPING_CART));

25:  }

 

Line 24 is the redirect and FILENAME_SHOPPING_CART is "shopping_cart.php"

 

Compare to a working redirect call right above this in the same file:

 

checkout_shipping.php

16: // if the customer is not logged on, redirect them to the login page

17:  if (!tep_session_is_registered('customer_id')) {

18:    $navigation->set_snapshot();

19:    tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL'));

20:  }

 

notice the empty single quotes on Line 19. This is the $parameter for tep_href_link(). Also, the 'SSL' argument should be assumed by tep_redirect(), that's what it's for!

 

Anyway, as I was copying and pasting the snippets, I thought I'd add the empty second argument and 'SSL' third argument to see what happens.

 

Viola!

 

It works now without my alternate redirect(). However, the fact that I had to do all this is still justification for "strange behavior."

 

Looks like I'm back to checking all 188 entries...