Looking through the module, there appears to be no way to force https in the Instagram block. This is a problem for secure sites in that it throws a security warning and confuses the user in to thinking something is wrong with the site certificate. Is there a known solution for this?
Peace,
Michael Clendening
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | non_secure_instagram-2337769-10.patch | 1.35 KB | yanniboi |
| #9 | non_secure_instagram-2337769-7.patch | 1.37 KB | yanniboi |
| #6 | non_secure_instagram-2337769-6.patch | 1.36 KB | yanniboi |
| #5 | non_secure_instagram-2337769-5.patch | 1.13 KB | joelpittet |
| #4 | non_secure_instagram-2337769-4.patch | 1.12 KB | joelpittet |
Comments
Comment #1
Anonymous (not verified) commentedIt looks the folks over in the Drupagram issue queue have already solved the https problem for their module. I am no developer, maybe someone here can take a look what they did and adapt it to this module.
https://www.drupal.org/node/1971098
Peace,
Michael Clendening
Comment #2
Anonymous (not verified) commentedAnyone interested in getting Instagram Block working on secure pages? While I am not a programmer, it seems the recipe to get this working is over in the Drupagram queue.
Peace,
Michael Clendening
Comment #3
pix_ commentedHi mclendening
here's a quick patch that allows instagram_block to make https request when drupal is under https. I followed the same approach as Drupagram folks because looks quick and easy.
This patch should apply fine against both dev and current stable version (7.x-1.1).
Hope it helps!
Comment #4
joelpittetWhat about simply using // for the protocol and it will take the protocol that the site is using?
Saves from preg_match and the global. Also fixed a typo in the template.
Comment #5
joelpittetwell strtr didn't work as I expected, back to trusty str_replace() :) almost as fast.. (9% slower ish #microoptimization)
Comment #6
yanniboi commentedI like it, but I'm a bit weary of hardcoding the url scheme... Maybe something a little more like this?
Comment #7
joelpittetThat seems robust, I'm not sure the performance implications of parse_url() though I bet it's minor, specially if the block is showing 9 images.
For some reason your patch didn't apply with patch -p1... just applied it manually though to test.
Comment #8
joelpittetWhoops spoke too soon, would you mind rerolling that @yanniboi?
scheme doesn't have "://" so the url becomes: "//://scontent..."
Comment #9
yanniboi commentedNo problem! sorry about the cowboy coding, but I haven't got time atm to actually spin up a site an test myself :P
Comment #10
yanniboi commentedPatch (7) #9 no longer applies so I am re-rolling.
Comment #11
yanniboi commentedI am happy to commit this.
Comment #13
yanniboi commentedComment #14
joelpittetThanks @yanniboi!