I hope this hasn't been covered, though I would think it has. Is there a way to get Amazon images delivered by https? I'm using the secure login module, and the only errors are showing on pages where book covers are coming over http://ecx.images-amazon.com/images/

Comments

willvincent’s picture

Hmm.. It looks like that domain does have SSL available, though the certificate it uses is for *.cloudfront.net, so it could potentially throw unverified warnings.

I wonder if we can just change the image urls to use protocol relative urls..

in other words:

<img src="//ecx.images-amazon.com/images/[image-file]" />

instead of:

<img src="http://ecx.images-amazon.com/images/[image-file]" />
wxman’s picture

That's actually what I was thinking, but I don't think there is a way without changing the module. Unless there is a way to hack it through template.php.

willvincent’s picture

I'm willing to change the module to do this so long as it doesn't break anything ;)

willvincent’s picture

for the time being, try running this query:

update amazon_item_image set url = replace(url, 'http://', '//');

and report back whether that fixes the issue for you or not. If so, and it doesn't break things, we'll update the module to do this when items are inserted into the DB.

wxman’s picture

After I ran the query an example book looks like:
<img src="//ecx.images-amazon.com/images/I/51oHwrkeiAL._SL160_.jpg" alt="The Mark of Athena (Heroes of Olympus, Book 3)">

This seems to work when on HTTP, but if logged in using HTTPS it breaks the image. If I manually type https in front of the url, it says there is no secure server.

willvincent’s picture

Interesting, I'm able to access that image via https. But as I mentioned previously, the browser complains because the SSL cert is for *.cloudfront.net NOT for *.images-amazon.com

Probably out of luck on this one, unless someone wants to write a patch to cache images locally.

wxman’s picture

After doing a bit of research, I found links like this:

https://images-na.ssl-images-amazon.com/images/I/51oHwrkeiAL._SL160_.jpg
instead of this, like now:
http://ecx.images-amazon.com/images/I/51oHwrkeiAL._SL160_.jpg

Using the new link directly caused no error. I don't understand why Amazon doesn't include that in the XML data stream. I tried figuring out where I could add a

str_replace('http://ecx.images-amazon.com','https://images-na.ssl-images-amazon.com',$img_url);

. The only place that worked was in a page tpl for one content type. That wouldn't work for things like view displays, etc.

willvincent’s picture

Hmm.. I'll have to look at the code to see if there's a place that can be added so that any time image links are output they have the proper base url for the protocol being used to access the site then.

Probably won't get to it til sometime over the weekend.

Thanks for the additional info!

willvincent’s picture

Category: support » feature
willvincent’s picture

I'd be curious as to whether these URLs are locale specific, though in a little bit of testing with a couple of items from amazon.co.jp (items that do not appear to be available from amazon.com) I was still able to access the image at image-na.ssl-images.amazon.com

I'll work on a patch, but this is one case were it will need to be heavily tested by people in various locales before the patch is commit i think.

willvincent’s picture

Status: Active » Needs review
StatusFileSize
new2.05 KB

Ok.. This should work. But, as mentioned previously, needs lots of testing in various locales before it'll be commit.

wxman’s picture

I'll try the patch today. I have to do patches manually because I never seem to get to work like designed.
I read through a few Amazon PDF white papers on setting up various requests through XML. All of the example they give use the HTTPS address, except for one about requesting major appliances for some reason. I don't know if it makes any sense, but I wonder if it would be better to make it an admin choice whether to get images via secure or unsecured? That way if there is a problem with a location, viewer's browsers, or random Internet weirdness, the admin can switch to HTTP.

wxman’s picture

I applied the patch, and it seemed to work well to begin with. I'm not positive yet, but I think caching messes it up. I have, for example, a panel page showing bestselling books, and in one browser the cover shows, but another it won't. Checking the log shows a lot of Error accessing Amazon AWS web service with query ... errors that match the missing books. I tried it as both logged in, and not logged in. I kept the browser, and site caches cleared out, but it would still have random missing covers. That all stopped once I removed all the views caching on the page, then flushed all the caches.

On a related issue, I also have panel pages showing different taxonomy views book listing. These came up empty on everyone but the admin when viewed. I tried clearing everything I could, but the only thing that worked, was removing the views cache. As far as I know, none of these problems were happening before the patch. If I get time, I'll go back to the unpatched version, and turn the caching back on.

UPDATE: I went back to the unpatched amazon-7.x-1.x-dev version. The missing covers still show up at random along with the Error accessing Amazon AWS web service with query ... error. This seems to occur on a HTTP page more so than HTTPS. I confirmed this by opening a new browser, not logged in, and viewed my bestseller page. Many of the covers were missing, but even if I stayed logged out, but opened the same page in the same browser using HTTPS, the covers showed up. This is with caching still off, so that isn't the problem, or your patch. Obviously there's something strange going on here with Amazon covers not related that I didn't catch before.