certficate problem HTTPS, mixed passive content problem with templates and woocomerce integration

I thought I had all my issues with the Woocommerce / Realtime Designer integration figured out. Then I Got the ssl cert going on my site to protect my buyers data and now I have problems again.
Everything is fine until after selecting a template category.
once I select a category, the images with links to each template shows up but nothing happens when I click on any of the template image/links .
Also when the Template images are displayed the secure information (green padlock) in the web browser goes to unprotected (displays a warning sign). Inspecting the page elements I find that the template category links are https links, but the individual template links are NOT https and the images are also not coming from a secure location. This causes a "mixed passive content problem" and in current versions of chrome and firefox that means clicking on the "unsecured link" won't take you to the template. This is for user protection against hacking but means that my customers can't choose a template to edit unless they know how to add a security exception.

I tried setting the main RTD URL in the plugin configuration to https://designer.realtimedesigner.com but that breaks the disigner even soner by not even showing template categories - it goes right to a $methodName_failedSL certificate problem: unable to get local issuer certificate.
Individual template links break completely of I don't use https:// - the designer window just pops up blank.

So, any idea if I have something configured wrong or any way i can fix the problem I am having?



Edited 1 time(s). Last edit at 10/26/2016 12:19PM by sffndude.

I brought this up before. For the time being it looks like we all will be in a mixed http and https environment with rtd. https for payments only and everything else http. I envision at some point the entire rtd ecosystem will be forced to transition to https because that is the way of the future and coming sooner than we know. Another hurdle for the rtd team to jump over. Hopefully we can all get there painlessly.

Oh.

Wonderful.

This has not been fun for our stores as well. We've been spending the last couple weeks trying to figure out what we can do. Cos is right. This future is coming sooner than we know. Right now just from the point of user access. Even if we convert our RTD designer from a popup to a standalone page it's still using http. Google is already giving more SEO weight for sites that use https and ssl compared to sites that do not. It seems that it will be worse next year. There are many features of RTD that we love. It's very robust, flexible, and does a lot that many competitors still can not do. One of the main features is user uploads of Vector PDF and EPS. There are plenty of lower priced options that support SVG uploads but not all three vector file formats. RTD can and does it at a reasonable cost. Plus it's rare to find an online design tool where you can communicate with the creator. The service is top notch as Alex and the RTD team are quick and responsive. They're really nice guys too.

I'm not a programmer but I can't see how RTD can fit to the https and ssl requirements without a complete overhaul. I'm assuming that everything needs to be in one location for it to be "secure". The design tool, clipart library, user artwork and any other data might have to be in the same host for each individual RTD user's store. That is a big transition. I blame Google for this new issue. It's their choice to frown on and block http pages in their Chrome browser (that most use). It's also their choice to penalize sites that continue to use http instead of https. Yah, I know I should probably put the blame on malicious hackers but evil seems to be around everywhere and anywhere. To me it feels like Google is taking advantage of an easy short cut to add extra security. Honestly I can't blame them. I'm just frustrated at all of this.

I have an idea on how to make it work for our site and am talking it over with my sysadmin... if it works I will let you know. It would not be pretty and I doubt Google will like it, nor would it be future-proof. But it would be a stopgap.

Let me jump in the discussion too. I have some random thoughts about all of this I'd like to share. "Thinking out loud" mode on!

Everyone is right: RTD, right now, is not meant to be served under HTTPS.
However, the actually is SSL in there. We are already using it for sensible pages like checkouts through RTD, as well as several admin pages.

The internal setup is both "silly and clever": in short, every content (single link) we have can be invoked and works as HTTPS too.
For example, the RTD logo in the designer. It's link is:
http://designer.realtimedesigner.com/graphics/rtdlogo.gif
but if you try to call it as HTTPS it will still work fine:
https://designer.realtimedesigner.com/graphics/rtdlogo.gif

And this is true for EVERYTHING in the RTD. However, again, only for direct calls.
This means 2 things, mostly.

1st, related to API integration. If your problem is mixed contents because you're showing an image from the RTD (like a template image or an order thumbnail into a secure cart), then a fix exists: just modify your API script to simply replace http: with https: in returned image URLs. This can be very effective to solve issues in custom templates browsers, carts and checkouts where RTD images are meant to be shown

2nd, WHOLE RTD links (designer).
Invoking the API or an RTD link with the SSL version is not going to help. This because you might be invoking the designer with an SSL url, true. But everything loaded by it and into it will still be non-ssl, and so mixed contents will still happen.
On top of that, technically, the SLL and non-SSL versions of an URL are technically different domains. This means that creating mixed contents with the two will also cause issues with cookies and sessions (which are set and valid only for one domain).
All of this, plus the legacy problem of not breaking every existing RTD URL is mostly the problem of a full transition.

If I will force the API or the designer to go HTTPS, everyone invoking the other version would be having issues.
Only alternative would be to force a redirect to SSL versions when an non secure link is called, but this is not as straightforward as it might sound: the RTD allows TONS if different kind of links, and a move like this would affect them all. Close to impossible to test all of the possibilities.
An extra issue is for those RTD users having white label and custom domains: SSL version can be only the one served by our server, and so an SSL version would force them all to expose the fact they're using the RTD - and hiding this is exactly what they're paying extra for.

As a final thought, although I recognize that Google is doing this, the RTD is still a link to an external server: it is not in hosted in YOUR pages in any case. For this, even if not SSL, it should not downgrade your website because it is simply not part of it: it is LINKED from it.
The only case where this is not true is when you use API to embed specific contents, but as I said on top this can be solved. Direct image URLs can be string-replaced, and results of API would be served by you and so would be SSL already.

The other scenario is iframe embed: but that's where a good developer can be helpful. Embedding is nice, but mixed contents will make this harder and harder.
In strict SSL compliance, even SSL'd websites that are not from the same domain will cause a warning. This means that in future, even an SSL version of the RTD will give warning if embedded with frames into another SSL website.
So, when it will be about calling the designer itself, opening standalone will always be the safest choice. And for everything that's just requiring API calls, SSL version can be coded.
A template browser, for example, can be easily adapted for an SSL site: just edit the script to string replace template thumbs and have the links opening in a new window. This would allow to embed a full template browser into an SLL website with no problems.

Pardon my rambling, I just want to get this down.

I wish my testing showed what Alex was talking about, but if I try to access the https:// version of a design I get an incompletely loaded designer. I could post screenshots if you like, but my point is the designer does NOT seem to work for me in https.
http link - https link

A possibility... if the woo-commerce plugin could open an actual new window instead of an iframe I could get things to work. (pop up blocker issue maybe?)
I noticed if I open a design link in a new tab (as http:// ) that I can edit the design normally, and even send it back to the woo-commerce cart. Unfortunately that also leaves the previous tab sitting there with an open iframe.
Oh and the cart page gets a security warning because the thumbnail isn't coming from an https source either.... there is an https version available tho, so that would just be a little code tweak I'm guessing.

The options my sysadmin has suggested are less savory.

Hope everyone else is having a better Halloween Monday!

Actually, waht I said is PRECISELY that adding HTTPS for a designer link would not work:

Quote

Invoking the API or an RTD link with the SSL version is not going to help. This because you might be invoking the designer with an SSL url, true. But everything loaded by it and into it will still be non-ssl, and so mixed contents will still happen.

So yeah, I said and I repeat: the designer CANNOT be invoked as SSL.
And opening in a new standalone page is exactly the solution to this I mentioned:

Quote

So, when it will be about calling the designer itself, opening standalone will always be the safest choice. And for everything that's just requiring API calls, SSL version can be coded.

As for the cart, if you have it under SSL, the only mxed thing you would have from the RTD would be the thumbnail. And as I said, that can be coded to be served as HTTPS:

Quote

If your problem is mixed contents because you're showing an image from the RTD (like a template image or an order thumbnail into a secure cart), then a fix exists: just modify your API script to simply replace http: with https: in returned image URLs. This can be very effective to solve issues in custom templates browsers, carts and checkouts where RTD images are meant to be shown

Perhaps I was just writing too "techincal", but really I already answered all of your concerns from a tech perspective in my previous post.
As for the ability to open in a standalone window the RTD from the Woo commerce, that takes a very easy edit to the plugin files.
In the RTD/WOO plugin there is a file named js_functions.php
Edit it, and look for the LaunchRTD function on top. The version you have should look like this:

function LaunchRTD(rtdlink,new_close_text,new_close_alert) {
	RTD_closepopup_text='';
	RTD_closepopup_alert="Close";
	if (new_close_text) RTD_closepopup_text=new_close_text;
	if (new_close_alert) RTD_closepopup_alert=new_close_alert;
	if ('ontouchstart' in window) {
		sshwin=window.open(rtdlink, "_blank");
		sshwin.focus;
	} else {
		document.getElementById('rtd_frame_container').style.display='block';
		document.getElementById('rtd_closebutton').innerHTML=RTD_closepopup_alert;
		document.getElementById('rtd_frame').src=rtdlink;
	}
}

Just replace it to look like this instead:

function LaunchRTD(rtdlink,new_close_text,new_close_alert) {
	sshwin=window.open(rtdlink, "_blank");
	sshwin.focus;
}

This will force all of your calls to open the current iframe into a standalone new window instead

Yeah I was obviously Monday impaired when I posted back to you.
Definitely read one of the things you said completely the opposite of what you actually said.
Thanks for still trying to help me out.
I should be able to dig back into it on Wednesday and will go back over your posts a few times before I try to get into changing any functions.
And I'll let you know the results, good, bad or confused
Hopefully it can help someone else down the line too.

I think the concepts are pretty clear. Now it looks like you're struggling more in how to actually implement the changes you need.
As I mentioned, tech workarounds are easy to put in place. At least, they are from my developer's perspective.
But in case you will not feel confident in applying those changes yourself, you can always open a support ticket. For the changes discussed here we're talking about a "project" that would hardly cost you more than 50 bucks.
Just to let you know!

We have the same problem with this and are wondering when rtd team will be tackling this hurdle. We hope sooner than later.

Techincally we could be ready in a not super-long period.
But all the considerations I wrote in my previous replies about currnet RTD links and strict compliance for frames are still valid.

I am open in discussing the issue, and what we're doing here is precisely that: discussing the issue.
I am presenting what the drawbacks would be (remember, every change made to the RTD would immediately affect each and every RTD user in each and every setup/implementation) and I'm trying to determine which could be possible solutions by brainstorming with everyone.

My probelm here is not technical: the solution is not technically hard to apply. My problem is how it should handle all of the current RTD linking. A silly example are integrations: if I'd simply force every call to be redirected to HTTPS, how would a setup built expecting a direct working URL react? Would I risk to stop some company's biz all of a sudden?
And consider that migrating to HTTPS means that EVERYTHING should be HTTPS. So, not only the RTD url, but also each and every image and link you have in there (including icons). This would result in an obviously slower system for everyone.
Another real world one? What about users who included custom code that invokes external images/scripts? Even those calls, being in the page, would trigger a mixed content warning. And this could affect almost everyone who simply decided to link a logo of their from their own website.

So, THIS is really what we're brainstorming about. That said, how would you foresee a possible realistic solution?
I am sorry about this, but my job is mainly to be sure everyone will still be able to do their biz without breaking what's already in place, and this means a LOT of currently live scenarios to keep in mind.

Alex. Thank you for the informative descriptions. I think what would be helpful is a clear roadmap of what to do on the company side and then, the corresponding roadmap of what companies need to do on the RTD side. I would be glad to help in illustrating that. A check list could help.

Is there any way for you to accept both http and https? Meaning that companies can add a call that tells rtd "we are using http so do this" or "we are using https so do this".

I've read that when using frames, as long as source and target sites are fully https, there should be no errors. Is this correct? If not, then I guess a lot of us will need to start thinking quite differently about our integrations.

Here's my possible plan.

I already made some tests to force every little piece of the RTD to be served as HTTPS.
It wokred of course, but it was done on a test company only. The thing is to understand if and how much it would slow down things if used massively.
For this, in a couple months, my plan would be to make an experimental option available only to some selected companies, where they can decide if they want to test this. Being used under controlled access, it should help understanding the real impact on systems.
Of course, while that test will be running, the feture will not have to be considered final. In the event some major rework of the RTD will be required to run it properly, the beta will be revoked.

In simple terms, the idea would be to allow some companies to test it but with the knowledge it might not last. So, to be used only for some specific scenarios/products I'd say.

Could you clarify more what is "if and how much it would slow down things if used massively.". Are you referring to the fact that each image used will need to be fetched from an external https address? Or what?

This is a good read



Edited 1 time(s). Last edit at 05/11/2017 10:45AM by cos.

Yes, I am referring to the impact on the system as well as the serving speed of everything. WIll read the good read in the next days