Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X
Hello,
Whenever, we make REST call, it creates a new connection which we can see under Monitoring->Users Logged In. However, it doesn't close the connection even after completion of the service.
var params = {
headers: undefined,
url: "http://localhost:8082/Thingworx/Resources/EntityServices/Services/DeleteUser/",
username: "xxxx",
password: "xxxx",
ignoreSSLErrors: true,
withCookies: true,
timeout: 30,
content: {user: "abc"}
};
Resources["ContentLoaderFunctions"].PostJSON(params);
When we make call using app key it doesn't create new connection.
var header = {
"appKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Content-Type": "application/json"
};
var params = {
headers: header /* JSON */,
url: "http://localhost:8082/Thingworx/Resources/EntityServices/Services/DeleteUser/",
content: {user: "abc"}
};
Resources["ContentLoaderFunctions"].PostJSON(params);
Can we have the difference between two methods ? or Is there is anyway to close the connection ?
Solved! Go to Solution.
Hello Nirav, I have looked at the behavior of Thingworx's HTTP Basic authenticator to see why sessions are being created. The authenticator will create a new session for each REST call authenticated using HTTP Basic authentication unless explicitly told not to. This is to accommodate REST calls made by the browser, which will not know to explicitly ask for a session for the default login. You could add the following header to ask the HTTP Basic authenticator to explicitly not create a session though:
x-thingworx-session: false
If a session gets created from a REST call, it will automatically expire after 30 minutes, so these sessions will eventually disappear.
There is another problem with this method, however, and it is that HTTP Basic authentication is slow. This is purposeful to avoid brute force attempts at guessing any password. Using application keys is the preferred practice for your case, as it avoids both the purposeful slowness of HTTP Basic, but it also avoids the extra sessions created; authenticating using an app key does not create long-lasting sessions by default.
Is there any reason you cannot use the second method here? The second is best practice because app keys are designed to be used in this way. They are tied to a user, so permissions can be granted exactly the same way in either case.
Hi, there is no reason for me to not to use second method. As soon as I found dangling connections I did switch to app keys. I understand it's best practice. However, it doesn't answer my questions.
Hello Nirav, I have looked at the behavior of Thingworx's HTTP Basic authenticator to see why sessions are being created. The authenticator will create a new session for each REST call authenticated using HTTP Basic authentication unless explicitly told not to. This is to accommodate REST calls made by the browser, which will not know to explicitly ask for a session for the default login. You could add the following header to ask the HTTP Basic authenticator to explicitly not create a session though:
x-thingworx-session: false
If a session gets created from a REST call, it will automatically expire after 30 minutes, so these sessions will eventually disappear.
There is another problem with this method, however, and it is that HTTP Basic authentication is slow. This is purposeful to avoid brute force attempts at guessing any password. Using application keys is the preferred practice for your case, as it avoids both the purposeful slowness of HTTP Basic, but it also avoids the extra sessions created; authenticating using an app key does not create long-lasting sessions by default.
The answer is pretty much here.
appKey assumes sessionless transaction unless otherwise specified using x-thingworx-session
user name and password assumes the reverse unless otherwise specified