Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X
There are a lot of new and exciting changes included in ThingWorx 8.0.0, which is due out today, and no doubt, you'll want to get a test environment set up to try them out. But there are a few changes that could impact your ability to get up and running with a new server that I wanted to share with everyone.
In ThingWorx 7.4.0, a new Licensing Subsystem was introduced, and the license file required was provided as part of the ThingWorx 7.4.0 platform download. As of ThingWorx 8.0.0, the license.bin file will no longer be provided with the platform download, but will instead need to be downloaded from the PTC Licensing Tool on the PTC eSupport Portal.
As part of the operating system specific Installing ThingWorx (OS) sections in the Installing ThingWorx 8.0 guide, additional steps have been added that outline how to use the PTC Licensing Tool to download and install the ThingWorx license file for your organization.
The license file downloaded from the ThingWorx Licensing Tool must be renamed to license.bin and copied to the /ThingworxPlatform directory prior to starting ThingWorx for the first time. The server will fail to start if it cannot find this license file.
For more information:
KCS Article 264374 - ThingWorx 8.0.0 Licensing
In order to help encourage the use of secure passwords for the Administrator account on ThingWorx servers, the default Administrator account password will be changing in version 8.0 and above. The new Administrator password is a complex password containing mixed case and special characters. This will encourage administrators to change their default, fully-privileged account password to one that is more secure and conforms to their organizational security standards.
Information about the new default password can be found in each of the operating system specific Installing ThingWorx (OS) sections of the Installing ThingWorx 8.0 guide.
PTC strongly advises against the use of any default password on any product, and encourages administrators to immediately change any default password to a proper, complex password.
For more information:
As part of an effort to better secure the ThingWorx Platform, the use of Application Keys as URL parameters (through the ‘appkey’ parameter) is being deprecated in ThingWorx 8.0.0.
For example, the following URL uses the now deprecated ‘appkey’ parameter to pass in an application key:
When included in the URL, the ‘appkey’ parameter becomes a browser-cacheable, clear-text rendition of a usable application key. A knowledgeable user could retrieve this application key from their browser history and use it to perform unauthorized actions against a ThingWorx server.
For full security, GET and POST requests that are run against a ThingWorx server should be performed over an HTTPS connection and should include the required application key in the request’s headers. Query string parameters are visible in both HTTP and HTTPS contexts, and by moving the application key into the request headers, the application key itself is encrypted as part of the HTTPS request. (Note that the application key in a header is still visible for plaintext HTTP connections though!)
By default, new installations of ThingWorx 8.0.0 will have the Allow Application Key as URL Parameter option disabled. Upgrades from previous versions of ThingWorx will retain the ability to use the ‘appkey’ query string parameter, but PTC strongly encourages customers to promptly update any solutions that are dependent on sending the appkey using a URL parameter to move to request headers instead. Please note that a future release of ThingWorx may completely disable the use of application keys as URL parameters.
The Allow Application Key as URL Parameter option can be enabled or disabled on the ThingWorx PlatformSubsystem’s configuration page, accessible at System > Subsystems > PlatformSubsystem > Configuration.
For more information:
Starting in ThingWorx 8.0.0, the Everyone organization will no longer be granted default visibility across all entity collections. Only users who are a member of the Administrator group will be able to see ThingWorx entities on a newly installed server; any additional visibility permissions will need to be explicitly granted by the Administrator.
This is a change in behavior from the previous ThingWorx releases where the Everyone organization (of which the all-encompassing Users group was a member) was granted visibility access by default to all entity collections. Visibility permissions had to explicitly be removed by the Administrator during solution development, which could be overlooked.
For more information:
Is there any change on thingworx deploy architecture? such as fully HA support with horizontal scaling.
Is there an officially recommended approach for providing access to mashups without requiring a username and password? Historically, App Keys have been used for accessing mashups without expressly requiring an end-user to enter a username and password, but as noted in this article it opens up the risk of that App Key being used for other purposes... and with App Keys being deprecated, I'm curious what PTC's recommended approach is.
Josh Lyon Feng Zhong it's best to open separate threads with those questions in the NextGen Composer group.
Josh Lyon quick note - app keys are *not* being deprecated. Instead of placing them in the url, they'd go in the header - and currently, the feature can be still enabled for legacy customers. In the future, however, it will be fully gone.
"For full security, GET and POST requests that are run against a ThingWorx server should be performed over an HTTPS connection and should include the required application key in the request’s headers."
"The Allow Application Key as URL Parameter option can be enabled or disabled on the ThingWorx PlatformSubsystem’s configuration page, accessible at System > Subsystems > PlatformSubsystem > Configuration."
Hi polina,
could you please tell me how to pass application key in headers as parameters, can you post the sample headers.
I tried application key string in headers in many formats, but still I am facing the same issue(cors).
I tried below cases:
headers:{
appKey: <application key>,
ApplicationKey: <application key>,
Application Key: <application key>,
Application-Key: <application key>,
application-key: <application key>,
KEY:<application key>,
}
can you please tell me how to pass application key in headers.
Hi could you please open a new thread with this question for tracking and organizational purposes? Thank you!
Yeah sure polina.
Thanks.
Hi,
Can we use once downloaded license file second time also ?