cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
106
Views
0
Helpful
0
Comments
cdnadmin
Level 11
Level 11
This document was generated from CDN thread

Created by: Mark McCahill on 30-10-2012 09:36:27 AM
It appears that in both the SDK and cloud versions of WebEx Social 3 support for OpenSocial gadgets is somewhat broken.

 
 If you have an OpenSocial gadget that needs to grab several libraries, your web browser will make several GET requests to fetch those assets, but only the first GET will use the server's DNS name - the GETs that follow will use the IP address of the server. This can cause either extreme slowness to render or outright failures of gadgets.
 
For instance, if the WebEx Social server is in the cloud and behind a NAT device, your web browser will be trying to fetch frpm non-routable 10.x.x.x IP addresses) and those requests will nevere succeed. If you are running against the SDK version of WebEx Social you can also see odd behaviour, depending on whether you access the server via DNS name or IP address.
 
For example, consider this open social gadget:
http://widgetweb.co.uk/gadgets/sheep.xml
running against an instance of the SDK, I see this sort of behavior in the Firefox web console on my browser
(first a GET with the DNS name for the machine running the SDK, followed by two GETs using the IP address of the server):

 
[09:38:28.058] GET http://wbxscdv30110000194.oit.duke.edu/quadopen/gadgets/ifr?container=default&viewer=U-10261&owner=C-611120&aid=611379&mid=3&country=US&lang=en&view=default&parent=http://wbxscdv30110000194.oit.duke.edu&st=78f34c86726426dd7695ee956cd49d1aa015dea4a1d3... Object] [HTTP/1.1 200 OK 23ms]

 
[09:38:28.121] GET http://67.159.81.242/quadopen/gadgets/js/views:core!core:rpc.js?container=default&nocache=0&debug=1&c=0&v=de7cfc18f4d959f70d7116b8558f54fa&jsload=0 [HTTP/1.1 200 OK 23ms]

 
[09:38:28.122] GET http://67.159.81.242/quadopen/gadgets/concat?container=default&gadget=http://widgetweb.co.uk/gadgets/sheep.xml&debug=1&nocache=0&type=js&1=http://pagead2.googlesyndication.com/pagead/show_ads.js [HTTP/1.1 200 OK 17ms]

 
Here the first request used the DNS name for our SDK, and those that followed used the IP address (67.159.81.242).
You may be able to get away with this behaviour if your WebExSocial instance is not NATted, but once a NAT or proxy is added to the mix, big trouble follows - your browser will be attempting to fetch from the private IP address of the server, like this:
 
[10:29:48.270] GET https://duke.webex-social.com/quadopen/gadgets/ifr?container=default&viewer=U-1310157&owner=C-2910571&aid=3611284&mid=0&country=US&lang=en&view=default&parent=http://duke.webex-social.com&st=3bce346ae059461926689fa6bcd11f35d03ea8bbad0f6350c79d83af9bd... Object] [HTTP/1.1 200 OK 54ms]

 
[10:29:48.327] GET https://10.240.188.191/quadopen/gadgets/js/core:rpc.js?container=default&nocache=0&debug=1&c=0&v=f882f58f5c34c4840b6a882d4f860244&jsload=0

 
[10:29:48.328] GET https://10.240.188.191/quadopen/gadgets/js/views:core!core:rpc.js?container=default&nocache=0&debug=1&c=0&v=de7cfc18f4d959f70d7116b8558f54fa&jsload=0

 
[10:29:48.329] GET https://10.240.188.191/quadopen/gadgets/concat?container=default&gadget=http://widgetweb.co.uk/gadgets/sheep.xml&debug=1&nocache=0&type=js&1=http://pagead2.googlesyndication.com/pagead/show_ads.js

 
Here the browser's first request went to the DNS name duke.webex-social.com, and the requests thaty followed went to 10.240.188.191 - presumably an internal IP address in a WebEx data center.
Since the 10.240.188.190 addresses are private, non-routable IP addresses, the browser is never going to get a responce if you are on the outside of the proxy or NAT looking in -- you will see either outright failure of the OpenSocial gadget or abysmally slow performance as the brwoser waits for the GETs to timeout.

 
It would seem there should be a simple configuration tweak that would fix this behavior and get the OpenSocial support in WebEx Social to always use the server name. Anyone have an idea of how to do that?

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Adrienne Moherek on 27-11-2012 05:22:53 PM
Hi Mark,
I'm taking a look at your post and we will work on reproducing it in the lab.
Thanks,
Adrienne

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Adrienne Moherek on 28-11-2012 05:32:03 PM
Hi Mark,
In the non-routable address example (10.240.188.191), is this something that you think could happen, or did this actually happen?
 
Thanks,
Adrienne

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Mark McCahill on 29-11-2012 01:18:37 PM
The non-routable address is something that actually happened at the duke.webex-social.com instance of WebEx Social.
All of the examples in my trouble report came from actual sessions either against an instance of the SDK run on-prem here at Duke or run by the webex operations people in the webex cloud.
My assumption is that the security guys are running parts of the server infrastructure on private address space, and the leakage of the server's IP address caused us to see non-routable addresses when the web browser was attempting to fetch parts of the OpenSocial gadget.  
Adrienne Moherek:
Hi Mark,
In the non-routable address example (10.240.188.191), is this something that you think could happen, or did this actually happen?
 
Thanks,
Adrienne


Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Adrienne Moherek on 30-11-2012 04:58:46 PM
Hi Mark,
We are working on configuring a similar environment so that we can test this out. Just to make sure I'm setting this up correctly, this is what we are doing:
We installed WxS dev edition on a VM on a web server. We have the web server behind a NAT'd address via a firewall. We've specified the DNS, public, and private IP address. Something isn't quite working yet, perhaps we need to configure something on the VMWare Player settings, but we will continue working on this.
Thanks,
Adrienne

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Mark McCahill on 01-12-2012 11:11:58 AM
You might contact Harold Pulhug and/or Shitalkumar Patel - they should have details on what they did to fix the problem for us in the production cloud instance at duke.webex-social.com

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Adrienne Moherek on 03-12-2012 06:07:22 PM
Hi Mark,

We were able to reproduce the issue so now we'll begin troubleshooting to figure out why the internal IP address is showing up.

thanks,
Adrienne

Subject: RE: OpenSocial Gadget support semi-broken?
Replied by: Adrienne Moherek on 04-12-2012 11:22:02 AM
Hi Mark,

To prevent WxS from using the internal IP address, set the domain name in the virtual host settings instead of the internal IP address.
Login as an admin user, go to Account Settings, click on Portal, click on Settings and change the Virtual Host from the internal IP address to the hostname. Click Save. Then restart WxS.
You should not see the internal ip address being used anymore.
Thanks,
Adrienne
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links