Admin using non-SSL domain name to build admin URLs

[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.

[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).

[DrByte]

Further to the above discussion, if you want your entire Admin to be SSL-protected, then set BOTH your HTTP_SERVER and HTTPS_SERVER to your https URL.

This is explained, in passing, in this article: http://www.zen-cart.com/content.php?...alled-zen-cart and is also the default in new installations of current versions of Zen Cart.

[omnicognate]

Ha, I was trying to obscure the actual URL by using example.com, but clearly I screwed up. I might as well paste the unmodified configure.php contents now, which I will do at the bottom. It was late last night - clearly I wasn't with it as I made a couple of other mistakes, see below :-) The problem is still unresolved.

The SSL error you were getting at secure.faircake.co.uk was because of an typo I made when restoring the rewrites/redirects after removing them for testing as mentioned in my earlier post. When restoring the config I accidentally disabled the SSL engine entirely. I have restored SSL, which works fine, as previously mentioned.

The rewrites are both rewrites and redirects. They are rewrites in the sense that they are implemented using Apache's mod_rewrite, via directives RewriteCond and RewriteRule. They are redirects in that they are configured to return a 301 permanent redirect respnse to the client.

In any event the rewrites/redirects are definitely not the source of the problem and can be eliminated from consideration as mentioned in my earlier post. I have tried removing them from the config entirely on both SSL and non-SSL domains, and disabling the rewrite engine altogether. It had no effect on the admin URL problem.

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.

That was just another late-night screw up when typing my post. The redirect is not from https to http, it is from https to https. My config has no redirect loops and in any event I've already verified that the redirects aren't causing the problem by removing them entirely.

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.

As I've already explained in an earlier post, I do not have any .htaccess in the ROOT folder. My rewrite rules are in the main httpd.conf, and again I have tested without those rules present so they are 100% certainly not the cause of the problem.

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).

I have been clearing the cache, cookies, history and all other clear options in Chrome and restarting the browser every time I test this. I am also pretty sure that browser state problems wouldn't be causing admin to build the internal link URLs with the wrong domain name.

Thanks,
Tom

Actual configure.php file contents. Admin:

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

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

Non-Admin:

  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'); 

[DrByte]

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

[omnicognate]

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

Oops, sorry DrByte, I missed your earlier post. That'll be it, I'm sure.

Thanks for your help!

Tom