VMware {code} Community
vromanowski
Enthusiast
Enthusiast

Questions on getting an external web server working with a Web Client plugin.

Hi all, this might be a little lengthy as I have quite a few questions. Any help is going to be really appreciated so thank you in advance.

I've been doing a lot of research and forum reading over the last few days and I think I have a good idea of what I need to do, and I want to confirm I'm heading down the right path. I am brand new to vSphere plugins but our vmware developer just left so it's been handed over to me Smiley Happy

We have an older 5.0/5.5 Client plugin that was registered with vCenter with an XML file. All it did was make HTTP requests to our external web server, and our external web server communicated with our CIM provider. The tab/view in the client would simply just display the HTML returned. I don't think the plugin even used any of the SDK, I think we just got the tab to appear via the XML registration and gave it the URL of the external server.

I'm tasked with getting this older plugin working with WebClient if possible, without rewriting it as web client plugin. Here are my questions and what I think are possible solutions:

How are Web Client plugins actually registered? It looks like registration is strictly through the plugin.xml manifest file, is that correct? Is the registration process different than the older client plugins?

Does that mean that a war file is required, even if we want to host the web app from an external host?

Possible solutions I’ve gathered from forum posts around here:

  1. Create a new Web Client plugin that acts as a proxy for the external web server. For example have a REST endpoint for each endpoint we want to support on the external server, and do our HTTP requests from inside these proxy methods and relay the response to the Web Client plugin.
  2. Create a new Web Client which just implements an IFrame which loads the external site. We’d have to use HTTPS in this case and use a certificate so it’s secure and doesn’t prompt the user with cross-domain warnings.

Are either of those options viable? Is there a better way? I’ve come across a few posts mentioning things like setting scriptplugin.enabled to true in webclient.properties, or setting allowHttp to true. But the context of those posts seemed different to what I’m trying to accomplish.


Edit: a few more questions about registration and such. It seems like the registration of web client plugins is kind of tied into the idea that a plugin is supposed to run in Virgo, which would explain why a war file is required and why using an external web server other than Virgo isn't straight forward. It would also explain why registration is strictly done through the plugin.xml (if I'm right). Is any of that correct?

Reply
0 Kudos
6 Replies
Peter_Ivanov
VMware Employee
VMware Employee

Hi,

I would recommend you to start with the samples that are in the public SDK. There is the so called "html bridge" that allows plugins, written in HTML to be displayed in the Web Client.

Please look at the sample. I believe they will give you most of the answers.

How are Web Client plugins actually registered? It looks like registration is strictly through the plugin.xml manifest file, is that correct? Is the registration process different than the older client plugins?

What you have currently is a plugin for the old desktop client, right? The registration process is completely different. It is described in details in

vsphere-client-sdk-6.0.0/docs/SDK-Tutorial.html#register-plugin-package

Does that mean that a war file is required, even if we want to host the web app from an external host?


Yes, you will need a war file. It must contain at least the plugin.xml that describes where your plugin will appear.

Check this out. I believe it contains the information that you need:

vsphere-client-sdk-6.0.0/html-bridge/docs/html-tutorial.html#existing-webapp


2. Create a new Web Client which just implements an IFrame which loads the external site.

Don't go this way. This is already done and provided to you for free by the HTML bridge.


1. Create a new Web Client plugin that acts as a proxy for the external web server. For example have a REST endpoint for each endpoint we want to support on the external server, and do our HTTP requests from inside these proxy methods and relay the response to the Web Client plugin.


You will need this if (and as I understood is the case) you need your web pages to be provided through https. And this is done to avoid the browser warnings.

If your pages were served by http, then you wouldn't need anything but the plugin.xml - no code at all.


setting scriptplugin.enabled to true in webclient.properties, or setting allowHttp to true.


scriptplugin.enabled I think is no longer supported. Also please not that this should be done by the customers of your plugin. And I don't think you wanna do this.

allowHttp enables downloading (installing) your plugin from http server. This is related to the plugin registration and not to its work. And it is done only for development purposes.


It seems like the registration of web client plugins is kind of tied into the idea that a plugin is supposed to run in Virgo, which would explain why a war file is required and why using an external web server other than Virgo isn't straight forward. It would also explain why registration is strictly done through the plugin.xml (if I'm right). Is any of that correct?

Virgo server has nothing to do with it. The war file (and the plugin.xml file inside) is required because this is the extensibility mechanism provided by the Web Client.

Using external server is straight forward if it serves the content using http. The necessity of java proxy is due to the browser cross-domain policies and has nothing to do with the Web Client or its extensibility.

Hope this helps Smiley Happy

Reply
0 Kudos
laurentsd
VMware Employee
VMware Employee

Also, if your old plugin was indeed a "script plugin" written for the C# client you can easily port it to the HTML bridge.   See the FAQ article Can I re-use my legacy script plugin code? in /html-bridge/docs/html-FAQ.html#script-plugin

Reply
0 Kudos
vromanowski
Enthusiast
Enthusiast

Thanks for the responses guys,


I don't need HTTPS, the old plugin used HTTP. I was just concerned that since the html is coming from an external server it was going to give cross-domain warnings/errors.

So it sounds like all I need is an empty war file with a plugin.xml specifying where to show the plugin and the URL to fetch?


I’m not sure if it qualifies as a legacy "script" plugin. I'm not sure what you mean by the "script" part. It was definitely for the old C#/.NET client, and all it did was serve html from an external server over http (it did not use https). Do you think it qualifies as this? That would be great, as the instructions under Can I re-use my legacy script plugin code? seem straight forward.

I guess my only remaining question is does it sound like I need to follow the steps in Can I re-use my legacy script plugin code?, or the steps under Integration of Existing Web Application ?

Reply
0 Kudos
laurentsd
VMware Employee
VMware Employee

A legacy script plugin is a javascript plugin written for the old vSphere client (Windows).  The view URL contains specific parameters (moref, sessionId, serverGuid) which will be added if you use the <legacyScriptPlugin> flag as explained in the FAQ.

Reply
0 Kudos
vromanowski
Enthusiast
Enthusiast

I am close, I set up a very bare bones project that works when I point the HtmlView to a relative html page, but is blank when I change the <url> in the plugin.xml to an external url (either our external web server or something like google).

Attached is my simple project if you wouldn't mind taking a look at it. Maybe this will make it more clear as to what I'm trying to accomplish, if I didn't explain it well before.

Reply
0 Kudos
laurentsd
VMware Employee
VMware Employee

You cannot use an http URL for your embedded view because this is insecure content.  Either you use a relative URL (i.e. the normal way as shown in all SDK samples) or you must use https.

FYI, the warning below is part of the HTML-Bridge documentation under Manage and Monitor views at html-bridge/docs/html-bridge.html#object-views

https URLs can also be used to display content from another domain in that view, but the content won't load the first time the user goes there, unless the certificate was already verified. http URLs won't work, modern browsers blocks insecure content inside the secure Web Client domain. Although they are ways around this for testing purposes.

Reply
0 Kudos