Problems with configuring for shared SSL checkout - CSS reference is wrong

[rdesignista]

Hi,

I have a question. I am setting up a shared SSL for Zencart (my client doesn't want to pay for a private one).

I was able to set up the shared SSL for the admin area with no problems, but the checkout one is bugging me a bit.

We are using a temporary nameserver (to upload stuff before we officially change the website). Our temporary address for the store is servername.net/~aimaa/store. Our shared SSL address is servername.net/~aimaa. Our server name after we perform the upgrade will be http://www.aimaa.com.


Here is what I have for includes/configure.php:

define('HTTP_SERVER', 'http://servername.net');
define('HTTPS_SERVER', 'https://servername.net/~aimaa');

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

// NOTE: be sure to leave the trailing '/' at the end of these lines if you make changes!
// * DIR_WS_* = Webserver directories (virtual/URL)
  // these paths are relative to top of your webspace ... (ie: under the public_html or httpdocs folder)
  define('DIR_WS_CATALOG', '/~aimaa/store/');
  define('DIR_WS_HTTPS_CATALOG', '/store/'); 

Now this works fine technical-wise, but during the checkout process, when the SSL kicks in, the page CSS isn't loaded because it's reference is wrong: it's /store/includes/templates/premium4a/css/stylesheet.css' , when it should actually be ~aimaa/store/templates... . I know it's doing this because the DIR WS HTTPS CATALOG is only listing /store/, but if I change the DIR WS HTTPS CATALOG to /~aimaa/store/, then the URL will become /~aimaa/~aimaa/store... and I will get a 404 error. Interesting note: even though CSS doesn't load, text and pictures seem to all have the right reference.

I feel like either this is a simple issue or I am facing a unique problem because of my name-of-directory vs name-of-ssl situation. My Plan B is to basically manually include the css files into checkout headers... but I want to ask the people here to see if I may be misunderstanding the configuration.

Thank you.

-R

[rdesignista]

Ok, so I kind of figured it out. I went with these settings (the default during installation):

  define('HTTP_SERVER', 'http://servername.net');
  define('HTTPS_SERVER', 'https://servername.net');

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

// NOTE: be sure to leave the trailing '/' at the end of these lines if you make changes!
// * DIR_WS_* = Webserver directories (virtual/URL)
  // these paths are relative to top of your webspace ... (ie: under the public_html or httpdocs folder)
  define('DIR_WS_CATALOG', '/~aimaa/store/');
  define('DIR_WS_HTTPS_CATALOG', '/~aimaa/store/'); 

I find this strange because for my admin/includes/configure.php, I had to set my HTTPS server to servername.net/~aimaa. Weirdness. I guess I just don't understand directories all that much... and hope to never work with them again...

-R

[RodG]

I find this strange because for my admin/includes/configure.php, I had to set my HTTPS server to servername.net/~aimaa. Weirdness. I guess I just don't understand directories all that much... and hope to never work with them again...

-R

For your enlightenment. Setting the HTTP(S) server to servername.net/~aimaa and having it work is what is weird. This is not a servername. It is a URL (or URI for those so inclined).

The servername is the portion before the first '/' . Everything else is a directory path of the resource found on the server (including the '/')

The "~" is a shorthand method of specifying the *servers* home directory for any given user. Typically this would be something like /usr/home/ but on systems with lots of users it could be something like /usr/home2/a/b/c. This is not something that users can set. It is set by the server administrator according to their needs.

Cheers
Rod

[rdesignista]

Thanks for the note RodG. I actually have to re-configure after we re-direct our domain to our 2nd nameserver, so this will help the inevitable directory issues/shared-SSL issues I will see again.

It is a bit weird, but the hosting guys told me that servername.net/~aimaa is the shared SSL url, and since it does work for my admin, I guess it's not too bad... does this look right to you? I set it up for shared SSL for the entire admin area:

  define('HTTP_SERVER', 'https://servername.net/~aimaa/');
  define('HTTPS_SERVER', 'https://servername.net/~aimaa/');
  define('HTTP_CATALOG_SERVER', 'http://servername.net');
  define('HTTPS_CATALOG_SERVER', 'https://servername.net/~aimaa/'); 

[RodG]

Thanks for the note RodG. I actually have to re-configure after we re-direct our domain to our 2nd nameserver, so this will help the inevitable directory issues/shared-SSL issues I will see again.

It is a bit weird, but the hosting guys told me that servername.net/~aimaa is the shared SSL url,

They didn't tell you anything wrong. A servername and a URL are not the same thing. A URL consists of a servername *and* a path to the resource (in this case, the servername is "servername.net", the path is /~aimaa, and the URL is. as specified, servername.net/~aimaa

and since it does work for my admin, I guess it's not too bad...

The fact that it works isn't an indication that that 'its not too bad'. All that is really telling us is that when the defined servername is combined with a file/folder path it actually evalutes to a valid resource.

Example: Lets us assume that a valid resource is located at /thisfolder/thatfolder/anotherfolder/ on a server called "myserver.com".

Valid 'defines' for this would be
servername = http://myserver.com
theFiles = /thisfolder/thatfolder/anotherfolder/

When these elements/defines are combined they will produce a valid URL of http://myserver.com/thisfolder/thatf...anotherfolder/

Now, consider what happens if you define the elements like
servername = http://myserver.com/thisfolder/
theFiles = /thatfolder/anotherfolder/

When these elements/defines are combined they will produce the exact same URL as before, namely
http://myserver.com/thisfolder/thatf...anotherfolder/
As such things will work (at least most of the time).

The problem(s) will arise when the program only needs the servername for something or other (not the filepath). Such an instance would be when cookies are set/retrieved. In the first instance the cookie will be set for servername "myserver.com". In the second instance it will be set for an *invalid servername* of http://myserver.com/thisfolder/
Unpredictable problems can be expected.

Another example of potential problems is where there are several file paths needed, eg, images, includes, admin, and so forth. EG:

servername = http://myserver.com
images path = /images/
admin path = /admin/

The URL needed to access the images using these defines will evaluate to
http://myserver.com/images/ and the URL to access the admin files will evaluate to
http://myserver.com/admin/

Everything will be found where expected.

Now consider this slight variant:
servername = http://myserver.com/images
images path = /
admin path = /admin/

Note how I've just made the folder path a part of the servername. What happens now? If you attempt to access the images, the evaluated URL will be
http://myserver.com/images/
Perfectly correct, and it will work. However, if you now attempt to access the /admin/ folder, the URL will evaluate to
http://myserver.com/images/admin/

This will fail miserably with a '404 file not found' error because it is now looking for an admin folder within the images folder.

does this look right to you? I set it up for shared SSL for the entire admin area:

  define('HTTP_SERVER', 'https://servername.net/~aimaa/');
  define('HTTPS_SERVER', 'https://servername.net/~aimaa/');
  define('HTTP_CATALOG_SERVER', 'http://servername.net');
  define('HTTPS_CATALOG_SERVER', 'https://servername.net/~aimaa/'); 

[/QUOTE]

Based on the examples I've just provided you should be able to determine for yourself whether it is right or not.

Personally I will emphatically argue that it is wrong, but that doesn't mean it won't work, and I know for a fact that there are many people using configurations near identical to this (and as a result they will argue blind that it is 'correct').

Here endeth the lesson.

Cheers
Rod

[DrByte]

Ok, so I kind of figured it out. I went with these settings (the default during installation):

  define('HTTP_SERVER', 'http://servername.net');
  define('HTTPS_SERVER', 'https://servername.net');

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

// NOTE: be sure to leave the trailing '/' at the end of these lines if you make changes!
// * DIR_WS_* = Webserver directories (virtual/URL)
  // these paths are relative to top of your webspace ... (ie: under the public_html or httpdocs folder)
  define('DIR_WS_CATALOG', '/~aimaa/store/');
  define('DIR_WS_HTTPS_CATALOG', '/~aimaa/store/'); 

Yes, that is appropriate for the NON-ADMIN file.

I set it up for shared SSL for the entire admin area:

  define('HTTP_SERVER', 'https://servername.net/~aimaa/');
  define('HTTPS_SERVER', 'https://servername.net/~aimaa/');
  define('HTTP_CATALOG_SERVER', 'http://servername.net');
  define('HTTPS_CATALOG_SERVER', 'https://servername.net/~aimaa/'); 

Yes, that is acceptable for the ADMIN configure.php file, as long as your DIR_WS_xxxxx settings don't include the ~aimaa references.


Working with folders is simple: you just don't want to repeat any of the same folders in your DIR_WS_xxxxx settings that you've already got in your HTTPxxx_SERVER settings.
It's usually simplest to put the special foldername in the HTTPS_SERVER setting, since if you change that at a later date, you won't need to change any of the DIR_WS_xxxx stuff.