Quote Originally Posted by mesnitu View Post
Thanks
But why there are two define('HTTP_SERVER', 'https://el_site.net'); ( in the admin configure ) ?

And also, to see if I'm understanding this right:

define('ENABLE_SSL_CATALOG', 'true'); is used IF there's a mix of http / https, right ?

In this case, as both define('HTTP_SERVER' / define('HTTPS_SERVER' are equal or https, it really doesn't matter if is set to true or false, or it does ?

Sorry for the dumb questions, but I'm trying to understand.

Thanks
Not dumb questions.

So first, there should really be only one *active* HTTP_SERVER define in the admin. Even if there is more than one, the first occurrence is the one that will be used. Once a "variable" is defined, it becomes a constant. Any additional occurrence of the define for that "variable" will be ignored though a notice is generated. (default ZC operation ignores these notices, but they are still created.)

As to the ENABLE_SSL_CATALOG... you almost have the right concept. The "problem" is that when code has been written, it generally has been from the perspective that there will be a define for HTTP_CATALOG_SERVER that is expected to begin with http: and a define for HTTPS_CATALOG_SERVER that begins with https:. Then the thought also was that a page need only be presented as https: in certain conditions such as when personal or financial information was to be transferred.

Thing is that other "services" have since decided that all pages should be provided via https: regardless of the content.

Well, because software was built with the before mentioned "logic", the *only* time that https: was to be encountered was when ENABLE_SSL_CATALOG was set to true and that if it were not set to true, then "obviously" the site did not support https: and therefore there may be an action or response to indicate that the site did not support https:... from a logic perspective, it seemed sound. But... it did not account for the possibility that HTTP_CATALOG_SERVER could be set to https: as well and therefore https: was supported at all times and not just when ENABLE_CATALOG_SSL was set to true.

So... really the issue is that downstream in other code, the attempt to ensure security of the information is/was too stringent and would prevent operations that would "appear" to be acceptable, but were determined to be "unsafe" because the safety inspection was limited in scope.

So, there are a few options depending on what you are willing to deal/work with...

You could continue to operate as suggested in the FAQ about how to enable SSL or you can go against the grain, identify code that is overly restrictive and offer up solutions that recognize the condition set of all https with the applicable ENABLE_SSL or ENABLE_CATALOG_SSL setting set as false. In older ZC versions it was identified that some of the payment modules built into ZC did not fully recognize the setting to false and both defines set to https: (more of an issue on the catalog side, though one of the payment methods does/did disable itself if the store was determine to not "properly" support https:).

That help make some sense of things?