It's probably going to become more popular to run Koha in SSL environments - currently on ssl, with Amazon images enabled, a SSL enabled site will either not show Amazon images (IE, some versions of Firefox?), or show a warning to users about mixed secure and insecure content (Firefox, Chrome). Since we now have the using_https template variable, it makes sense to use it.
Created attachment 21431 [details] [review] Bug 10944 - Mixed content warnings in opac results and detail with Amazon images on https It's probably going to become more popular to run Koha in SSL environments. Currently on ssl, with Amazon images enabled, a SSL enabled site will either not show Amazon images (IE, some versions of Firefox?), or show a warning to users about mixed secure and insecure content (Firefox, Chrome). Since we now have the using_https template variable, it makes sense to use it. To test: In each browser you have access to, and preferably with SSL set up (you can set up a self signed cert for your dev install by following, more or less, the instructions here: https://wiki.debian.org/Self-Signed_Certificate) For the apache config, just copy the one for the OPAC, but set it to use 443 instead of 80 for the port, and point it to your keys per the instructions above. ** note that using a self signed cert on your dev install will prompt you when you connect the first time that OMG I CAN'T VERIFY THIS IS COOL. You did it yourself, if you can't trust yourself... then who can you trust? * Enable Amazon images in the system preferences * Do a search that you know will have images for, verify that without SSL 1. the images show 2. the image source is from an Amazon url that uses http:// 3. the images are the right size, and look ok * Do the same using https, verify that with SSL 1. the images show 2. the image source is from an Amazon url that uses https:// 3. the images are the right size, and look ok Clicking on the image should link to the item on Amazon. This patch also corrects a problem with the Amazon url used on the images - it was pointing to a feature that is currently unavailable. That's fixed here. All you need to check is that it goes to a valid Amazon endpoint that doesn't show an error.
Patch applied cleanly, go forth and signoff
Created attachment 21839 [details] [review] Bug 10944 - Mixed content warnings for covers on staff client This switches the URLs used to access Amazon's cover images to the SSL image server, preventing warnings when using this on a secure site. To test: * Enable Amazon images in the sysprefs, all other cover images off. * Do a search in the staff client. Using firebug or similar, inspect the images that indicate both "no image found" and the covers. * Are they all https, and showing correctly?
Created attachment 21886 [details] [review] Bug 10944 - Mixed content warnings for covers on staff client This switches the URLs used to access Amazon's cover images to the SSL image server, preventing warnings when using this on a secure site. To test: * Enable Amazon images in the sysprefs, all other cover images off. * Do a search in the staff client. Using firebug or similar, inspect the images that indicate both "no image found" and the covers. * Are they all https, and showing correctly?
Ed, you've marked this as signed off but haven't attached a signed off version of the patch, was that intentional?
I think it looks like bug number confusion.
Created attachment 22407 [details] [review] Bug 10944 - Mixed content warnings in opac results and detail with Amazon images on https It's probably going to become more popular to run Koha in SSL environments. Currently on ssl, with Amazon images enabled, a SSL enabled site will either not show Amazon images (IE, some versions of Firefox?), or show a warning to users about mixed secure and insecure content (Firefox, Chrome). Since we now have the using_https template variable, it makes sense to use it. To test: In each browser you have access to, and preferably with SSL set up (you can set up a self signed cert for your dev install by following, more or less, the instructions here: https://wiki.debian.org/Self-Signed_Certificate) For the apache config, just copy the one for the OPAC, but set it to use 443 instead of 80 for the port, and point it to your keys per the instructions above. ** note that using a self signed cert on your dev install will prompt you when you connect the first time that OMG I CAN'T VERIFY THIS IS COOL. You did it yourself, if you can't trust yourself... then who can you trust? * Enable Amazon images in the system preferences * Do a search that you know will have images for, verify that without SSL 1. the images show 2. the image source is from an Amazon url that uses http:// 3. the images are the right size, and look ok * Do the same using https, verify that with SSL 1. the images show 2. the image source is from an Amazon url that uses https:// 3. the images are the right size, and look ok Clicking on the image should link to the item on Amazon. This patch also corrects a problem with the Amazon url used on the images - it was pointing to a feature that is currently unavailable. That's fixed here. All you need to check is that it goes to a valid Amazon endpoint that doesn't show an error. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 22409 [details] [review] Bug 10944 - Mixed content warnings for covers on staff client This switches the URLs used to access Amazon's cover images to the SSL image server, preventing warnings when using this on a secure site. To test: * Enable Amazon images in the sysprefs, all other cover images off. * Do a search in the staff client. Using firebug or similar, inspect the images that indicate both "no image found" and the covers. * Are they all https, and showing correctly? Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I have followed the instructions and set up https, but I am confused by the results: OPAC Still running on localhost:8080, but the Amazon cover URL appears as https:// on the results page and on the details page. Intranet Now working with localhost and 442, but the Amazon cover URL is still http:// on the results and the details page. Liz, can you please check?
I think I've got to the bottom of why I couldn't get this to work.. It's not implemented in the bootstrap theme. Could someone do a follow-up with bootstrap support please?
Created attachment 23280 [details] [review] Bug 10944 - Followup for Bootstrap Amazon images on https OPAC see test plan for previous patch, only bootstrap theme instead of prog. :)
Hi Cait, I wasn't able to replicate your issue - the image url changed correctly for me based on whether or not the site was running in SSL in the OPAC. You would need both patches to cover both OPAC and intranet. The intranet patch doesn't even have a non-ssl mode for fetching the images - you will always get the ssl version of the image no matter the mode. The thinking is - we should not ever be running (yes, of course we *do* but we *shouldn't*!) the intranet in non-SSL. It doesn't hurt anything to fetch the https image over the http version, so Robin simply made that choice to do it without the ability to switch.
Hi Liz, That's all looking pretty good to me now, though there is one minor discrepancy that's crept in on the bootstrap theme. in http the class=item-thumbnail whereas in https class=thunmbnail which make the image display slightly differently depending upon http or https. Though it's no biggy (I actually prefer the styling on the https version myself with a minor border). I'm currently testing to see if it affects the results turned up for .com vs other local amazon's, and testing that the other amazon preferences aren't affected. I think cait's issues were to do with her ssl setup so she's asked me to do qa.
Created attachment 23282 [details] [review] [PASSED QA] Bug 10944 - Mixed content warnings in opac results and detail with Amazon images on https It's probably going to become more popular to run Koha in SSL environments. Currently on ssl, with Amazon images enabled, a SSL enabled site will either not show Amazon images (IE, some versions of Firefox?), or show a warning to users about mixed secure and insecure content (Firefox, Chrome). Since we now have the using_https template variable, it makes sense to use it. To test: In each browser you have access to, and preferably with SSL set up (you can set up a self signed cert for your dev install by following, more or less, the instructions here: https://wiki.debian.org/Self-Signed_Certificate) For the apache config, just copy the one for the OPAC, but set it to use 443 instead of 80 for the port, and point it to your keys per the instructions above. ** note that using a self signed cert on your dev install will prompt you when you connect the first time that OMG I CAN'T VERIFY THIS IS COOL. You did it yourself, if you can't trust yourself... then who can you trust? * Enable Amazon images in the system preferences * Do a search that you know will have images for, verify that without SSL 1. the images show 2. the image source is from an Amazon url that uses http:// 3. the images are the right size, and look ok * Do the same using https, verify that with SSL 1. the images show 2. the image source is from an Amazon url that uses https:// 3. the images are the right size, and look ok Clicking on the image should link to the item on Amazon. This patch also corrects a problem with the Amazon url used on the images - it was pointing to a feature that is currently unavailable. That's fixed here. All you need to check is that it goes to a valid Amazon endpoint that doesn't show an error. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 23283 [details] [review] [PASSED QA] Bug 10944 - Mixed content warnings for covers on staff client This switches the URLs used to access Amazon's cover images to the SSL image server, preventing warnings when using this on a secure site. To test: * Enable Amazon images in the sysprefs, all other cover images off. * Do a search in the staff client. Using firebug or similar, inspect the images that indicate both "no image found" and the covers. * Are they all https, and showing correctly? Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 23284 [details] [review] [PASSED QA] Bug 10944 - Followup for Bootstrap Amazon images on https OPAC see test plan for previous patch, only bootstrap theme instead of prog. :) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I'm happy that this all works as advertised and doesn't introduce any regressions anywhere. It passes the QA script and even tidies up the templates a little. I corrected the minor discrepancy in class upon thumbnails in opac-results for bootstrap as it was a very minor change to make.
Created attachment 23285 [details] [review] [PASSED QA] Bug 10944 - Followup for Bootstrap Amazon images on https OPAC see test plan for previous patch, only bootstrap theme instead of prog. :) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 24633 [details] [review] Bug 10944 - opac-user and opac-readingrecord had instances of non-https amazon images To test: * Enable Amazon images in the system preferences * Issue a book you know will have images for, verify that without SSL 1. the images show on the borrower's logged in home page (opac-user) and on the opac-readingrecord 2. the image source is from an Amazon url that uses http:// 3. the images are the right size, and look ok * Do the same using https, verify that with SSL 1. the images show on the borrower's logged in home page (opac-user) and on the opac-readingrecord 2. the image source is from an Amazon url that uses https:// 3. the images are the right size, and look ok
Should add that while I was in there I added the reference to the amazonTLD systempref.
Comment on attachment 24633 [details] [review] Bug 10944 - opac-user and opac-readingrecord had instances of non-https amazon images I think the amazonTLD preference isn't working properly, so I'll submit a new patch without that additional change.
Pushed to master. Thanks, Liz and Robin!