https padlock does not show on member sign up page
Posted: October 21st, 2011, 8:55 amWe use s2member-Pro (version 110915) and have set up a new member sign up page with the custom field s2member_force_ssl = yes. We also use the Share-And-Follow plugin to output a few 'follow' icons in the page header.
When we navigate to the sign up page s2member correctly forces it to use SSL. But we noticed that the browser (IE, FF, or Chrome) did not show the usual padlock sign, to indicate that the site was fully secure.
After several hours digging I realised what was happening; Share-And-Follow outputs links that look like '<a href='https://domain/file.php' ... style='background: url(https://domain/file.png)' and then s2member forces BOTH instances of https back to http before outputting the page. The browser sees an <a> tag with an href that uses http, which is OK, and a style attribute that uses http (ie refers to an unsecure local asset) which is NOT OK and so the browser does not trust the site and doesn't display the padlock.
For the moment I've hacked around this issue by replacing lines 138 to 140 of includes/classes/ssl-in.inc.php with
$s = preg_replace ("/href= *(\'|\")https\:\/\/" . preg_quote (_ws_plugin__s2member_force_ssl_host_port, "/") . "/i", "http://" . _ws_plugin__s2member_force_ssl_host, $m[0]);
$s = preg_replace ("/href= *(\'|\")https\:\/\/" . preg_quote (_ws_plugin__s2member_force_ssl_host, "/") . "/i", "http://" . _ws_plugin__s2member_force_ssl_host, $s);
This change means it only forces the href attribute to be http.
This may already be fixed in the latest version of s2Member and/or this is not the optimal way to fix this issue, but I thought others out there might like to know this one.
When we navigate to the sign up page s2member correctly forces it to use SSL. But we noticed that the browser (IE, FF, or Chrome) did not show the usual padlock sign, to indicate that the site was fully secure.
After several hours digging I realised what was happening; Share-And-Follow outputs links that look like '<a href='https://domain/file.php' ... style='background: url(https://domain/file.png)' and then s2member forces BOTH instances of https back to http before outputting the page. The browser sees an <a> tag with an href that uses http, which is OK, and a style attribute that uses http (ie refers to an unsecure local asset) which is NOT OK and so the browser does not trust the site and doesn't display the padlock.
For the moment I've hacked around this issue by replacing lines 138 to 140 of includes/classes/ssl-in.inc.php with
$s = preg_replace ("/href= *(\'|\")https\:\/\/" . preg_quote (_ws_plugin__s2member_force_ssl_host_port, "/") . "/i", "http://" . _ws_plugin__s2member_force_ssl_host, $m[0]);
$s = preg_replace ("/href= *(\'|\")https\:\/\/" . preg_quote (_ws_plugin__s2member_force_ssl_host, "/") . "/i", "http://" . _ws_plugin__s2member_force_ssl_host, $s);
This change means it only forces the href attribute to be http.
This may already be fixed in the latest version of s2Member and/or this is not the optimal way to fix this issue, but I thought others out there might like to know this one.