Symptom: The ThingWorx Remote Access Client (RAC) fails to connect to the platform when initiating a session
Here is an example of the RAC initializing a remote session with ThingWorx Platform:
As shown above, the RAC initially displays a "Connecting to Thingworx" message on the platform icon. When, after a period of time, the RAC cannot connect to the platform, the message, "Unable to connect to Thingworx", appears, as shown here:
The next three sections provide three possible causes and the actions that users and administrators should take to try to resolve the issue.
Cause: Invalid nonce key
As of v.1.2.0 of the RAE and v.1.1.0 of the RAC, a temporary single-use nonce key is used for authentication with a ThingWorx Platform instead of an application key. If the nonce key sent to ThingWorx Platform is invalid, the following actions should be taken:
• User or Administrator — When the RAC is launched through a mashup that implements the Remote Access Client Linker Widget, a temporary single-use nonce key is provisioned for use by the client when it is launched. If some delay causes the launch of the client to take longer than 15 seconds, it is possible the nonce key will no longer be valid. In this case, it might be possible to simply re-try starting a session. If you are using an earlier version of the RAC, that is prior to v.1.1.0, then it uses an application key, which is valid for 15 seconds.
Cause: Incorrect Proxy Settings
If RAC has been configured with incorrect proxy settings, users can check that the proxy settings entered in the UI of the RAC are correct. From the ellipsis menu, select Proxy Settings, as shown here:
In the proxy settings dialog, ensure that the proxy host and port are configured to point to a valid proxy server instance:
Administrators should confirm that RAC is configured to use a valid proxy server and port. Proxy servers requiring authentication are not currently supported. Only anonymous proxies are supported.
Cause: Platform Not an HTTPS Instance
Users should check the ThingWorx Platform they are using has an SSL/TLS-enabled endpoint configured and use that endpoint to initiate the session instead. An HTTPS browser session is required to connect securely to the platform.
Administrators can enable insecure access for the client in the config.json file. Along with proxy configuration, a flag can be specified in the configuration file to allow insecure access. The format of the file would be:
{
"secure": false,
"proxy": {...}
}
 | The insecure parameter in the configuration file enables or disables TLS for all connections made by the Remote Access Client, so it is not possible to connect to an insecure platform but a secure Remote Access Server, for example to a GAS. The default behavior of the Remote Access Client (if the secure flag is not specified) is equivalent to the secure property being set to true. |