Most tools that interact with APIs do not natively have this type of functionality built-in. Therefore, it's common to see requests to the API handled by different web applications. In workflows where a sequential series of operations must occur or where subsequent calls are dependent upon earlier calls, this can often be problematic due to the cluster refresh, which occurs every minute.
For API workflows that do not require all interactions to occur with a single web application, Jamf recommends not using the workflow described below. Directing all traffic to a single web application may negatively impact performance, especially for large automated processes.
To better understand when the use of sticky sessions are necessary, we'll examine an example scenario. Imagine a scenario where we would like to create a device group and add that group to the scope of an existing deployable resource. After creating the device group, there is up to a 60 second delay before all other web applications become aware of the newly created resource. An immediate request to update the deployable resource with the new device group could be routed to a web application other than the original one that created the smart group, resulting in a error response. These are the types of issues that can be prevented by using cookies to establish a sticky session.
- Request header information from any page or API resource. This can be done using the
-vflag for verbose responses or the
--headflag which will return only the header information.
i. When interacting with the Jamf Pro API, this can easily be included with your initial request for an authentication token similar to the following:
curl -v --header 'authorization: Basic Base64Credentials' https://company.jamfcloud.com/api/v1/auth/tokens -X POST
ii. When using the Classic API, if no initial requests are part of your workflow, a request to any page, including the login page, which returns header information, will provide the required information.
curl --head https://company.jamfcloud.com
iii. A sample response may look something like the following:
curl --head https://company.jamfcloud.com HTTP/1.1 401 Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0 Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0 Content-Length: 8921 Content-Type: text/html;charset=utf-8 Date: Wed, 08 Apr 2020 18:39:42 GMT Server: Jamf Cloud Node Set-Cookie: JSESSIONID=C29C9EC374DD304FADE008C160791315; Path=/; Secure; HttpOnly Set-Cookie: APBALANCEID=aws.use1-std-ellison4-tc-1; path=/;HttpOnly;Secure; Strict-Transport-Security: max-age=31536000; includeSubdomains; X-FRAME-OPTIONS: SAMEORIGIN Connection: keep-alive
- Parse the response for the "APBALANCEID" cookie as well as its value.
- Include this cookie and its value in all subsequent requests in your workflow that require interaction with a single web application.
curl -b "APBALANCEID=aws.use1-std-ellison4-tc-1" https://company.jamfcloud.com/JSSResource/endpoint
The use of cURL is provided only as an example to demonstrate the premise of using cookies while interacting with Jamf APIs. Many other tools and languages have libraries or features for managing and interacting with cookies, be sure to reference the documentation for your preferred tool of choice when interacting with Jamf Cloud hosted APIs.
Updated over 1 year ago