Jump to content

[SOLVED] HTTPS - insecure content checkout


Recommended Posts

Checkout page (quick-order) is displaying insecure content, specifically the thumbnail images displayed next to product description at checkout. As it appears the image links are absolute paths rather than relative I cannot see how to fix this.

 

Any suggestions please?

Link to comment
Share on other sites

Ok, possibly this has something to do with it. I am using a CDN (Max), SSL using my own cert (rather than their shared cert) requires a cname and custom cert (including the cname) which I have. So looking at an image at checkout the url is https://shop.mydomain.com/748-small_default/lg-ca-484ctq.jpg

 

The actual shop url while checking out is https://www.mydomain.com/quick-order.

 

If any expert here can advise any fix this type of scenario. Can a re-write rule in htaccess solve this? Don't really want to experiment on a live site but need this issue resolved, or I need to disable the CDN.

 

Thanks.

Link to comment
Share on other sites

Further inspection of the element and it appears to be not CDN related. Chrome Dev Tools points to this:

 

[blocked] The page at 'https://www.mydomain.com/quick-order' was loaded over HTTPS, but ran insecure content from 'http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js': this content should also be loaded over HTTPS.

Edited by jetx (see edit history)
Link to comment
Share on other sites

I wasted a lot of time on this. The error was caused by a mod (whos online). Disable the mod and the error disappears. Damned annoying waste of time, sloppy code.

 

edit: of course if I had used chrome's dev tools to begin with I would have found the culprit immediately!

Edited by jetx (see edit history)
Link to comment
Share on other sites

  • 2 months later...

I wasted a lot of time on this. The error was caused by a mod (whos online). Disable the mod and the error disappears. Damned annoying waste of time, sloppy code.

 

edit: of course if I had used chrome's dev tools to begin with I would have found the culprit immediately!

 

Hi jetx,

 

I am experiencing a similar problem, could you please explain a bit more in detail what was causing the error?  I would really appreciate pointers on this!

 

Thanks in advance!

 

Dan

Link to comment
Share on other sites

  • 4 weeks later...

Hi Dan,

 

That particular error was caused by that mod whois online, since been fixed I believe. However, the error you're having I believe was related to the search block as described here: http://www.prestashop.com/forums/topic/346307-chrome-ssl-error/?view=findpost&p=1819529 Which I realise you have been part of that discussion, so just made this post for any others who are searching for SSL errors.

  • Like 1
Link to comment
Share on other sites

Retrocompatibility of which versions of Prestashop?

 

First of all, the modules in question (blocknewsletter and blocksearch) have a min compliancy of PS v1.6

$this->ps_versions_compliancy = array('min' => '1.6', 'max' => _PS_VERSION_); 

Second, Link::getPageLink has $ssl as the second parameter going back to PS v1.4

 

PS v1.4

public function getPageLink($filename, $ssl = false, $id_lang = null)

PS v1.5

public function getPageLink($controller, $ssl = null, $id_lang = null, $request = null, $request_url_encode = false, $id_shop = null)

PS v1.6

public function getPageLink($controller, $ssl = null, $id_lang = null, $request = null, $request_url_encode = false, $id_shop = null)
Link to comment
Share on other sites

Both search and home page are not using https.

 

If you do like this you will have an automatic redirection on the search page.

That is your assumption, but that does not mean users have not forced SSL on every page. 

 

The point here is that if left unchanged, then you have insecure content warnings from major browsers.  The form actions should contain a secure URL, if a redirect occurs, then a redirect occurs. That does not break anything or introduce "Retrocompatibility" issues.

Link to comment
Share on other sites

That is your assumption, but that does not mean users have not forced SSL on every page. 

 

This is also an issue if you have not forced SSL - for example, in the case of my shop, which does not force SSL on all pages, I still got error warnings in Chrome on the checkout pages, which by default use https even if the rest of the website does not.

 

And having SSL warnings on the checkout page, that's pretty bad for customer trust right before he's deciding whether to commit to a purchase or not.

  • Like 1
Link to comment
Share on other sites

Dear all,

 

We spoke again with the developpers about this issue, and they corrected Blocksearch and Blocknewsletter, here are the comits :

 

https://github.com/PrestaShop/blocknewsletter/commit/0d8a3bc0ecdf6e94d337701a7d7b48a71e0dd696

 

https://github.com/PrestaShop/blocksearch/commit/8df3bf5f070e920b208a51f31d16ca6404ba412f

 

 

Best regards,

  • Like 4
Link to comment
Share on other sites

  • 2 months later...

This is also an issue if you have not forced SSL - for example, in the case of my shop, which does not force SSL on all pages, I still got error warnings in Chrome on the checkout pages, which by default use https even if the rest of the website does not.

 

And having SSL warnings on the checkout page, that's pretty bad for customer trust right before he's deciding whether to commit to a purchase or not.

Yes you are definitely right about this.customers are calling us and they are reporting about it so they are annoying to purchase an item

 

we are expecting to see "New Updates for modules"

Link to comment
Share on other sites

Yes you are definitely right about this.customers are calling us and they are reporting about it so they are annoying to purchase an item

 

we are expecting to see "New Updates for modules"

 

I believe there are updates available already for both, I updated my shop yesterday and compared the code to the github fixes to make sure the issue was corrected, and it seems so. For now, now more SSL warnings on my shop, so it looks good.

  • Like 2
Link to comment
Share on other sites

Same here. Can't see which module serve unsecure content but when I'm on 'secure' page I get warnings in the browser.

 

I only have facebook slider and yotpo v2 modules on checkout but when both of them are disabled the warnings still appear. 

 

I believe that if you use a tool like Pingdom, you can see all connections including those in https or regular http - same for Firebug or Chrome console. That should help you locate which resource on your page is not loading secure.

Link to comment
Share on other sites

  • 2 weeks later...

Hi

 

After updating the link,php getting following error

 

Strict Standards: Declaration of Link::getCategoryLink() should be compatible with LinkCore::getCategoryLink($category, $alias = NULL, $id_lang = NULL, $selected_filters = NULL, $id_shop = NULL, $relative_protocol = false) in /public_html/override/classes/Link.php on line 219

 

Help

 

Using 1.6.0.8

Link to comment
Share on other sites

×
×
  • Create New...