cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X

HTTP Basic authentication REST Call user count

nparikh
2-Guest

HTTP Basic authentication REST Call user count

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 ?

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

4 REPLIES 4
ttielebein
12-Amethyst
(To:nparikh)

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.

PaiChung
22-Sapphire I
(To:jasongi)

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

Top Tags