Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Upgrade from 2.3.1 to 2.3.4 result in admin login redirect loop


steevithak

Recommended Posts

Posted

I had an OSC site that was working great running on v2.3.1 until the ISP upgraded to php 5.4, which caused the OSC site to stop working and display only an empty white page. After reading the forums here I discovered OSC had bugs which caused this failure with PHP 5.4 and an upgrade to OSC v2.3.4 was recommended. I further read that a direct upgrade wasn't possible and that I would have to manually upgrade through each intermediate version one at a time (which is insane, incidentally! you guys should take a look at modern CMS system like wordpress where you upgrade in 30 seconds by clicking an "update" button!). Anyway, after several hours of manually making SQL changes, moving files around, double-checking each update, etc. I had all the updates done and OSC v2.3.4 was in place. At this point the public catalog seemed to work ok again, however any attempt to log in to the admin page produces a redirect loop. No PHP errors can be seen in the Apache error log.

 

A search revealed that redirect loops on admin login have plagued many OSC users who upgraded in the 2.3.x series but there seem to be many different causes for them. I'm not using any addons (it's a very simple site) so the problem would seem to be within the core OSC code somewhere. Here's what I've tried so far:

 

- cleared cookies, cache on browser

 

- tried entirely different browser

 

- added the fix.php file that loads global variables as described in this post:

http://www.oscommerce.com/forums/topic/335768-admin-login-loop/#entry1556982

 

- also, I DID add the new 2.3.4 parameters in the config file that are described here:

http://library.oscommerce.com/Online&en&oscom_2_3&release_notes&v2_3_4#upg14

 

- replaced my configure.php with the new one from 2.3.4 and manually added back in all the correct paths and values. (I should emphasize again that the config file was in place with 2.3.1 and has been working fine for years, so I don't think there's any error there).

 

Can anyone recommend other possible fixes? Even better, is there some way to diagnose the actual problem? What is OSC trying to accomplish by doing a redirect in the first place? Is there a way to simply comment out the PHP code that's doing the redirect? Any ideas appreciated.

 

Posted

I've started trying to debug this thing myself and here's what I've found so far. The redirect loop is caused by this code in application_top.php:

 

// if the first page request is to the login page, set the current page to the index page
// so the redirection on a successful login is not made to the login page again
    if ( ($current_page == FILENAME_LOGIN) && !tep_session_is_registered('redirect_origin') ) {
      $current_page = FILENAME_DEFAULT;
      $HTTP_GET_VARS = array();
    }


    if ($current_page != FILENAME_LOGIN) {


      if (!tep_session_is_registered('redirect_origin')) {
        tep_session_register('redirect_origin');


        $redirect_origin = array('page' => $current_page,
                                 'get' => $HTTP_GET_VARS);
      }

The problem is that when I hit the login.php page, the value FILENAME_LOGIN = 'login.php' while the value $current_page = 're/admin/login.php' so it sees the two as not equivalent and sends the browser around for another loop every time.

 

The full url is /store/admin/login.php and for some reason $current_page contains are badly parsed, incomplete path instead of just the page name. The same value is present in $PHP_SELF, which is where $current_page gets it. If I can figure out how that's getting mangled, I should be close to solving the problem...

Posted

Ok, so found one problem. It probably only affects weird edge cases like mine where the http and https are on different domains and/or have different pathnames. The current code uses this overly complicated mechanism to derive the page name from the request path:

 

$PHP_SELF = substr($req['path'], ($request_type == 'SSL') ? strlen(DIR_WS_HTTPS_ADMIN) : strlen(DIR_WS_ADMIN));

 

If, instead, PHP's built-in mechanism for getting the page name from the path is used, there are no problems and it works correctly no matter how weird the server config and path names might be:

 

$PHP_SELF = basename($req['path');

 

With this change, the redirect loop is solved. Unfortunately, I'm on to another problem, an internal server error in action_recorder.php... :(

Posted

Hi Steve Rainwater, Below is the message i'm getting when i try to log into back office for my store is this due to the update? and how do i go about rectifying it i'm no web developer or coding genius 

 

Bennetto84

 

 

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /customers/5/2/d/giftprezzy.com/httpd.www/includes/functions/database.php on line 19 Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /customers/5/2/d/giftprezzy.com/httpd.www/includes/functions/database.php:19) in /customers/5/2/d/giftprezzy.com/httpd.www/includes/functions/sessions.php on line 102 Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /customers/5/2/d/giftprezzy.com/httpd.www/includes/functions/database.php:19) in /customers/5/2/d/giftprezzy.com/httpd.www/includes/functions/sessions.php on line 102 Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /customers/5/2/d/giftprezzy.com/httpd.www/includes/classes/seo.class.php on line 78 Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /customers/5/2/d/giftprezzy.com/httpd.www/includes/classes/seo.class.php on line 78

  • 3 weeks later...
  • 4 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...