Admin using non-SSL domain name to build admin URLs

[omnicognate]

Having migrated our site onto a new server, admin keeps logging out. This only happens when SSL admin is enabled - non-SSL admin is fine.

There appears to be a major clue in the fact that all of the internal links within the admin UI appear to have been constructed with the non-SSL domain name.

In our admin/includes/configure.php, we have:

  define('HTTP_SERVER', 'http://www.example.com');
  define('HTTPS_SERVER', 'https://secure.example.com');
  define('HTTP_CATALOG_SERVER', 'http://www.example.com');
  define('HTTPS_CATALOG_SERVER', 'https://secure.example.com');

  // Use secure webserver for catalog module and/or admin areas?
  define('ENABLE_SSL_CATALOG', 'true');
  define('ENABLE_SSL_ADMIN', 'true'); 

and in our includes/configure.php, we have

  define('HTTP_SERVER', 'http://www.faircake.co.uk');
  define('HTTPS_SERVER', 'https://secure.faircake.co.uk');

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

If I go to www.example.com/admin/, I get redirected to secure.example.com/admin/ for login. However, once I've logged in, all the links in the admin are to urls starting www.example.com/admin/, not secure.example.com/admin/, and when I click on any of them I get sent back to the login page.

This is with Zen Cart 1.3.9h. The config worked fine with the old server, and aside from this issue the site is live and well (with non-SSL admin). I've done the admin session caching fix, though I had to do it manually in PHPMyAdmin.

[schoolboy]

You migrated to a NEW server.

On the OLD server, the config for the SSL area was: https://secure.example.com

Are you sure that the NEW server is configured the same way?

Check with your host to ask what the correct path is for SSL.

On mine is is the SAME as http:

eg:

define('HTTP_SERVER', 'http://www.example.com');
define('HTTPS_SERVER', 'https://www.example.com');

[omnicognate]

I have root access to both servers and configured them myself. In both cases the SSL site is served from secure.example.co.uk and the non-SSL site from www.example.co.uk (the domain is actually .co.uk, not .com - relevant for rewrites below). I believe the configuration of SSL itself is correct. At least, I am able to use the site, and complete a full checkout and successful payment using SSL. It's only the admin that is experiencing difficulties.

It could conceivably be an issue with redirects? I have the following 301 rewrites configured:

http://example.co.uk -> http://www.example.co.uk
http://example.com -> http://www.example.co.uk
http://www.example.com -> http://www.example.co.uk
https://www.secure.example.co.uk -> http://secure.example.co.uk

I don't see how these could affect the URLs generated in admin, but I'm scraping the bottom of the barrel here - I thought those URLs were built based on the configure.php settings, but they look right.

[schoolboy]

I don't know why you are bothering with the re-writes. Zencart handles canonical issues with:

<?php if (isset($canonicalLink) && $canonicalLink != '') { ?>
<link rel="canonical" href="<?php echo $canonicalLink; ?>" />
<?php } ?>

in html_header.php

So get rid of any .htaccess in the ROOT folder.

Additionally, if you are using any of the stupid "SEO URL" modules, then junk them while you have a chance. They do nothing for your site - except cause problems.

[omnicognate]

The rewrites aren't there for providing canonical versions of zen cart pages. They don't appear to be causing the problem - I've tried disabling them and the problem persists.

I'm not using any SEO URL modules.

Can you confirm my understanding that these URL's are supposed to be generated based on the HTTPS_SERVER value in configure.php?

[gilby]

Both these configure.php files are set to read only.
You need to make them writable before changes will "take"

[omnicognate]

I'm not sure what you mean. The configure.php files have the same perms as the other php files in the installation. They have the right contents. I don't believe they have to be writable by the webserver user, and they weren't on the old site which worked fine. The config in them has clearly affected the execution of zen cart, since SSL checkouts are working and the initial admin login gets redirected to secure.example.co.uk.

The file ownerships and permissions are identical on the two servers, set using the same script.

The only other difference relating to SSL between the two servers that I can think of is that on the old server the secure.example.co.uk domain and the www.example.co.uk domain were on separate IP addresses. On the new server they share an IP address.

If necessary I can set the new server up with 2 IP addresses too. I'll try it tomorrow if I haven't resolved this. However, I didn't think separate IPs would be necessary. Is there any way the IP addresses could affect the generation of these URLs? It sounds far-fetched...

[omnicognate]

Hmmm, I see a call to gethostbyaddr() in includes/init_includes/init_sessions.php. Perhaps it isn't that far-fetched after all. It looks like it might be doing a reverse DNS lookup and getting the non-SSL domain back.

I'll try with separate IPs for SSL and non-SSL tomorrow.

[gilby]

You migrated to a NEW server.

On the OLD server, the config for the SSL area was: https://secure.example.com

Are you sure that the NEW server is configured the same way?

Check with your host to ask what the correct path is for SSL.

On mine is is the SAME as http:

eg:

define('HTTP_SERVER', 'http://www.example.com');
define('HTTPS_SERVER', 'https://www.example.com');

As you have migrated to a new server........

Why not migrate to a better and more contemporary way of doing ssl as well, as per schoolboy above.

[RodG]

The only other difference relating to SSL between the two servers that I can think of is that on the old server the secure.example.co.uk domain and the www.example.co.uk domain were on separate IP addresses. On the new server they share an IP address.

As long as there is only one SSL certificate being used by the shared IP address then this won't be causing your problem.

define('HTTPS_SERVER', 'https://secure.faircake.co.uk');

This has an invalid SSL certificate (or server has been incorrectly configured).

It could conceivably be an issue with redirects?

Yes.

I have the following 301 rewrites configured:

http://example.co.uk -> http://www.example.co.uk
http://example.com -> http://www.example.co.uk
http://www.example.com -> http://www.example.co.uk

These are re-directs (not rewrites). Depending on the history of the sites you'll probably be better off using ALIAS's rather than redirects, if not possible/suitable then using re-writes is better than using redirects.

https://www.secure.example.co.uk -> http://secure.example.co.uk

This is going to cause no end of headaches. Redirecting a https request to a http server is a classic setup for an endless loop.

As suggested by Schoolboy, get rid of any .htaccess in the ROOT folder. Yes, I/we are aware that you may have been using these rules for many years without any issue, but the fact remains, you *do* have an issue so these need to be eliminated from the equation until the cause if found. Then, and only then should you consider adding .htaccess rules to cater for specific and/or unusual needs.

Cheers
Rod.

ps. Always clear your cache files and/or refresh your browser when making any config changes. It is easy to lead yourself astray otherwise (experience speaking).