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

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

GetCookies constantly returns incorrect value

RD_8056414
2-Guest

GetCookies constantly returns incorrect value

I need to access a cookie value that's being set the first time I call GetAllStyleDefinitions using PlatformSubsystem. So far I've been using the GetCookies service in ContentLoaderFunctions. However, it always returns an incorrect value for that cookie, and the value changes every time I call the service.

For example, using the console viewer I can see that the cookie JSESSIONID has a value of JSESSIONID=C05EAE42A25C102A43AB6B3E985826FD. However, when I call GetCookies once, I get JSESSIONID=755A83EB72C6476FE77C2B69557F752E, and when I call it again I get JSESSIONID=5A46D418307B76DC917904DD9C3A56EF​ despite the fact that all the parameters are hardcoded so I don't know what could have changed between attempts:


I use these headers:

  1. ignoreSSLErrors:true
  2. proxyPort:"8080"
  3. proxyScheme:"http"
  4. timeout:60
  5. username:"daltonr"

as well as the url, domain, my user password


Is there something I'm missing in order to get the actual cookie value? There are no errors shown in the console viewer when I make the call to GetCookies. The value returned is just incorrect.

1 ACCEPTED SOLUTION

Accepted Solutions
sharmon
12-Amethyst
(To:RD_8056414)

The reason you're getting a new JSESSIONID each time you call the service is you're passing your username and password with each call. There are a couple of sessions at play - one is the session your browser creates when you authenticate to the Platform. The one that keeps changing is a session that's created inside the service every time the service uses your credentials to authenticate to the platform again.

Now, the next part is going to be frustrating to you, because I will explain what's happening, but I'm unable to offer you a solution. Here is a minimal call where I pass my username and password:

var params = {

  ignoreSSLErrors: true,

  url: 'http://192.168.99.100:8080/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleDefinitions',

  timeout: 500,

  password: 'mypassword',

  username: 'myusername'

};

// result: STRING

var result = Resources["ContentLoaderFunctions"].GetCookies(params);

Here are my results. Notice there are two JSESSIONIDs, one that comes back in the result, and one that you can see in the request headers:

Call-w-uid-and-pwd.png

The JSESSIONID in the Developer Tools was created by ThingWorx when you logged into the platform. It authenticates you for your service call. The JSESSIONID in the result is created by your service. The JSESSIONID in the service is created anew, every time you run it:

Call-w-uid-and-pwd-2png.png

Note that we have a new JSESSIONID in the result, but the one for your ​ThingWorx session​ stays the same.

Here's where I'm going to disappoint you. When I run my service ​without ​passing my credentials, the ThingWorx session JSESSIONID stays the same. I get nothing back in my result, though:

var params = {

  ignoreSSLErrors: true,

  url: 'http://192.168.99.100:8080/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleDefinitions',

  timeout: 500

};

// result: STRING

var result = Resources["ContentLoaderFunctions"].GetCookies(params);

Results:

Call-w-no-creds.png

I do not think there is an out-of-the-box way to reach up and get the cookies for the ThingWorx session, unfortunately. There are probably some good security-related reasons behind that decision. Perhaps someone will jump on the thread with a workaround.

View solution in original post

2 REPLIES 2
sharmon
12-Amethyst
(To:RD_8056414)

The reason you're getting a new JSESSIONID each time you call the service is you're passing your username and password with each call. There are a couple of sessions at play - one is the session your browser creates when you authenticate to the Platform. The one that keeps changing is a session that's created inside the service every time the service uses your credentials to authenticate to the platform again.

Now, the next part is going to be frustrating to you, because I will explain what's happening, but I'm unable to offer you a solution. Here is a minimal call where I pass my username and password:

var params = {

  ignoreSSLErrors: true,

  url: 'http://192.168.99.100:8080/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleDefinitions',

  timeout: 500,

  password: 'mypassword',

  username: 'myusername'

};

// result: STRING

var result = Resources["ContentLoaderFunctions"].GetCookies(params);

Here are my results. Notice there are two JSESSIONIDs, one that comes back in the result, and one that you can see in the request headers:

Call-w-uid-and-pwd.png

The JSESSIONID in the Developer Tools was created by ThingWorx when you logged into the platform. It authenticates you for your service call. The JSESSIONID in the result is created by your service. The JSESSIONID in the service is created anew, every time you run it:

Call-w-uid-and-pwd-2png.png

Note that we have a new JSESSIONID in the result, but the one for your ​ThingWorx session​ stays the same.

Here's where I'm going to disappoint you. When I run my service ​without ​passing my credentials, the ThingWorx session JSESSIONID stays the same. I get nothing back in my result, though:

var params = {

  ignoreSSLErrors: true,

  url: 'http://192.168.99.100:8080/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleDefinitions',

  timeout: 500

};

// result: STRING

var result = Resources["ContentLoaderFunctions"].GetCookies(params);

Results:

Call-w-no-creds.png

I do not think there is an out-of-the-box way to reach up and get the cookies for the ThingWorx session, unfortunately. There are probably some good security-related reasons behind that decision. Perhaps someone will jump on the thread with a workaround.

Well, at least I know for sure now. Thanks, Stephen. We have some workarounds we can go to, even if they're all going to be a bit clunky.

Top Tags