We've written a vCenter plug-in to run in the HTML web client and the Flash web client. We keep a small amount of data on disk on the vCenter.
The problem is that that HTML client is running as vsphere-ui and the Flash client is running as vsphere-client.
Previously we stored our data at /storage/vsphere-client, but now we can't access that data from the HTML client because of the
directory permissions. Currently I'm using Spring injection to store the HTML data at /storage/vsphere-ui and the Flash data at /storage/vsphere-client.
Is there a way that I could have a directory that both clients could access?
Not really. The HTML5 web-client is a complete re-write of the vSphere client so it is not really compatible with Flash file/folder structure.
Why is it so important for you to have all those files in one directory? Is your plug-in unable to differentiate between the two clients?
I'd suggest that you guys switch to storing data on the SolidFire backend side.
The directory layout of vCSA is not part of the API contract of vSphere and may change without an advance notice.
What is the type of information stored on vCSA? Is tied to the particular instance of the client? If not e.g. if it's user preferences, even if you solve the problem for Flex and HTML client, you'd still not be sharing the data with another vCenter instance (running a Flex and HTML client instances) in Enhanced Linked Mode.
How can I store data on the SolidFire backend if I can't store the SolidFire ip address/userid/password on the vCenter.
Some minimal amount of data MUST be stored to get to the rest?
You don't need to store the SolidFire IP - just cache it the first time a user makes a request to the plugin. The standard approach is to use the Extension.server array in vCenter ExtensionManager API and store another server entry for your backend endpoint. User credentials should not be stored - instead it is better to provide a vCenter GUID and vCenter username to your backend and have the backend validate the information with a call to the vCenter - using the SessionManager.SessionIsActive(sessionId, username) method. If the call succeeds the SolidFire backend can consider the session authenticated.