Skip to main content
N
nparikh1-Visitor
1-Visitor
August 9, 2017
Solved

HTTP Basic authentication REST Call user count

  • August 9, 2017
  • 2 replies
  • 4423 views

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 ?

Best answer by jasongi

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.

2 replies

T
ttielebein5-Regular Member
5-Regular Member
August 9, 2017

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.

N
nparikh1-VisitorAuthor
1-Visitor
August 10, 2017

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.

J
jasongi1-VisitorAnswer
1-Visitor
August 15, 2017

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.

    P
    PaiChung22-Sapphire I
    22-Sapphire I
    August 15, 2017

    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

    Terms & ConditionsAccessibility statement