I hacked this about in the Pixlr class in DAMP 2.7 by making the scheme (http/s) configurable.
It's easy enough to change the hard-coded scheme for the IframeUrl value to use https, but there's a follow-on problem where the image urls use the scheme from the HttpRequest. We're behind a load-balancer which does SSL-offloading, so the request on the server looks like http and the images then get blocked. To fix this I added a config setting value to tell Pixlr whether to run secure or not. If set to 'true' then it will build the image urls with https irrespective of the request scheme.
Could be more robust I'm sure, but I'll leave that as an exercise for the reader :). I'm not minded to fork the CodePlex repo and update atm as I think most efforts are on V7 atm.
I tried the same route, but as far as I know Pixlr.com doesn't support SSL. Does it work for you? The only way I could think of is to force all Pixlr calls to HTTP.
By the way, if you're using a load balancer you may be able to intercept the payload and change the Pixlr URL on the fly.
Pixlr seems to work fine with SSL: https://pixlr.com/editor/, as well as from our site's Umbraco back end.
And yes, intercepting the payload would be possible so that on the server side of the load balancers we're all http... but unfortunately we have a 3rd party running that part of our infrastructure which makes developer hands-on more difficult than the tweak I described above.
You probably know all this... but I found the browser developer tools very helpful. I looked at the network traffic + console when the site makes the Pixlr call so I could see the call being made and the SSL-related errors.
Very strange; I'm quite sure that in the past I wasn't able to use HTTPS to access pixlr.com. This morning I tried again (copied the URL from your reply) and again I was not able to connect. However, when I tried just now the site is accessible over HTTPS...
I'll try out your suggestions in Umbraco. I'm hopeful.
I was able to get it to work in the Pixlr project by changing the protocol in the JavaScript file (..\Umbraco\Plugins\pixlr\pixlr_minified.js):
function buildUrl(opt){var url='';for(var attribute in opt){if(attribute!='service')url+=((url!='')?"&":"?")+attribute+"="+escape(opt[attribute]);}
return'https://pixlr.com/'+opt.service+'/'+url;}
Thinking about your load-balanced environment a bit more, could you also resolve the issue by re-encrypting the traffic as it leaves the load balancer?
That's a cool fix - however I think our set-ups must differ: I don't explicitly have the Pixlr package in my solution, and I don't think it's explicitly in DAMP either.
And I'm sure there's lots could be done with the load-balancer, and the ops specialist here seems to agree. Our big problem though as I said is that we don't have easy access to them.
DAMP: Pixlr incompatible with SSL?
When I force Umbraco to use SSL for the backoffice I'm unable to use Pixlr in DAMP.
Any suggestions on how to make it work?
Hello,
I've never tried to use Pixlr when in SSL mode. You could check if the Pixlr package does work. If it doesn't it would be harder to solve.
Jeroen
Is there any update/fix on this?
I hacked this about in the Pixlr class in DAMP 2.7 by making the scheme (http/s) configurable.
It's easy enough to change the hard-coded scheme for the
IframeUrl
value to use https, but there's a follow-on problem where the image urls use the scheme from the HttpRequest. We're behind a load-balancer which does SSL-offloading, so the request on the server looks like http and the images then get blocked. To fix this I added a config setting value to tell Pixlr whether to run secure or not. If set to 'true' then it will build the image urls with https irrespective of the request scheme.Could be more robust I'm sure, but I'll leave that as an exercise for the reader :). I'm not minded to fork the CodePlex repo and update atm as I think most efforts are on V7 atm.
I tried the same route, but as far as I know Pixlr.com doesn't support SSL. Does it work for you? The only way I could think of is to force all Pixlr calls to HTTP.
By the way, if you're using a load balancer you may be able to intercept the payload and change the Pixlr URL on the fly.
Hi Arie,
Pixlr seems to work fine with SSL: https://pixlr.com/editor/, as well as from our site's Umbraco back end.
And yes, intercepting the payload would be possible so that on the server side of the load balancers we're all http... but unfortunately we have a 3rd party running that part of our infrastructure which makes developer hands-on more difficult than the tweak I described above.
You probably know all this... but I found the browser developer tools very helpful. I looked at the network traffic + console when the site makes the Pixlr call so I could see the call being made and the SSL-related errors.
Best Rich
Very strange; I'm quite sure that in the past I wasn't able to use HTTPS to access pixlr.com. This morning I tried again (copied the URL from your reply) and again I was not able to connect. However, when I tried just now the site is accessible over HTTPS...
I'll try out your suggestions in Umbraco. I'm hopeful.
I was able to get it to work in the Pixlr project by changing the protocol in the JavaScript file (..\Umbraco\Plugins\pixlr\pixlr_minified.js):
Rich,
Thinking about your load-balanced environment a bit more, could you also resolve the issue by re-encrypting the traffic as it leaves the load balancer?
That's a cool fix - however I think our set-ups must differ: I don't explicitly have the Pixlr package in my solution, and I don't think it's explicitly in DAMP either.
And I'm sure there's lots could be done with the load-balancer, and the ops specialist here seems to agree. Our big problem though as I said is that we don't have easy access to them.
is working on a reply...