New warnings from Firefox (Connection not secure)

Firefox is now complaining when pages which are non-SSL present forms for credentials even when those forms are sent back over SSL.
Here's a screenshot from the timeout page, which is called in NONSSL mode from a bunch of places (see list below).

We could fix this by modifying zen_href_link to look for "known" SSL pages, and switch $connection to 'SSL'.

if ($connection == 'NONSSL') { 
   if (in_array($page, array(FILENAME_LOGIN, FILENAME_TIME_OUT, FILENAME_CHECKOUT_PAYMENT, FILENAME_CHECKOUT_PAYMENT_ADDRESS, FILENAME_CHECKOUT_PROCESS, FILENAME_CHECKOUT_SHIPPING, FILENAME_CHECKOUT_SHIPPING_ADDRESS, FILENAME_CHECKOUT_CONFIRMATION, FILENAME_CHECKOUT_SUCCESS, FILENAME_ACCOUNT, FILENAME_ACCOUNT_EDIT, FILENAME_ACCOUNT_HISTORY, FILENAME_ACCOUNT_HISTORY_INFO, FILENAME_ACCOUNT_PASSWORD, FILENAME_ADDRESS_BOOK, FILENAME_ADDRESS_BOOK_PROCESS, FILENAME_CREATE_ACCOUNT_SUCCESS, FILENAME_CREATE_ACCOUNT, FILENAME_GV_SEND, FILENAME_PASSWORD_FORGOTTEN, ))) {
     $connection = 'SSL'; 
   }
}

This would save the trouble of tracking down every call which was not coded with SSL.

Calls to zen_redirect (zen_href_link (FILENAME_TIME_OUT)); i.e. no SSL:

./classes/ajax/zcAjaxPayment.php
./init_includes/init_customer_auth.php
./init_includes/init_sanitize.php
./modules/checkout_process.php
./modules/pages/checkout_confirmation/header_php.php
./modules/pages/checkout_payment/header_php.php
./modules/pages/checkout_shipping/header_php.php
./modules/pages/checkout_success/header_php.php
./modules/pages/download/header_php.php
./modules/pages/gv_send/header_php.php
./modules/payment/payeezyjszc.php

Good catch, @swguy! I believe, though, that the plan should be to correct the modules where the time_out page is "misused" rather than having zen_href_link provide that clean-up.

Plugin developers (like you and me) rely on the core code providing the "best practice" for the processing and hiding those issues with a function fix-up doesn't do that.

Perhaps doing both would be good - the trouble with just doing the core files is that a number of these are templates which were likely overridden, and also contain the flaw.

swguy:

Perhaps doing both would be good - the trouble with just doing the core files is that a number of these are templates which were likely overridden, and also contain the flaw.
I'll buy that, assuming that the list of pages is defined outside of the function-file to make it easier for stores to add additional pages that might be needed.

Would recommend also throwing in a check (before searching the array) if the site is not full ssl.

mc12345678:

Would recommend also throwing in a check (before searching the array) if the site is not full ssl.
Why? That's just extra processing required for each call to zen_href_link.

If the site was full SSL, this issue wouldn't happen. The issue occurs when the HTTP URL is "http://..." rather than "https://...", as would be the case in a full SSL site.

lat9:

Why? That's just extra processing required for each call to zen_href_link.

swguy:

If the site was full SSL, this issue wouldn't happen. The issue occurs when the HTTP URL is "http://..." rather than "https://...", as would be the case in a full SSL site.

Exactly. The issue (http: result) would not occur; however, the additional processing introduced by reviewing the array of pages to be accessed via https:// (unless one were to empty the array) would as written occur for each and every call to zen_href_link as compared to the up front comparison that would negate the need to search the array for each such use.

Ie. overall less processing for incorporation of this code when a site is set to use full SSL. Otherwise all sites are impacted for the reasons described above as a result of templates not being up-to-date with the call of 'SSL' in the original zen_href_link reference and for every link referenced on any given page.