Using cookies to make sure you hit the same server and reduce 409 errors

[Honestpuck]

Hey,

I've just written and debugged some code for PatchBot that should be useful for python-jamf. It uses a cookie (they are different for standard and premium JPC customers) that is returned by a request and can be passed back to get the same box. The variable self.cookie is for use in requests() calls as cookie=self.cookie, the variable c_cookie is for use in curl calls after a -b parameter.

        # let's use the cookies to make sure we hit the
        # same server for every request.
        # the complication here is that ordinary and Premium Jamfers
        # get two DIFFERENT cookies for this.

        # the front page will give us the cookies
        r = requests.get(self.base)

        cookie_value = r.cookies.get('APBALANCEID')
        if cookie_value:
            # we are NOT premium Jamf Cloud
            self.cookies = dict(APBALANCEID=cookie_value)
            c_cookie = "APBALANCEID=%s", cookie_value
        else:
            cookie_value = r.cookies['AWSALB']
            self.cookies = dict(AWSALB=cookie_value)
            c_cookie = "AWSALB=%s", cookie_value

The reference doc is
DR-StickySessionstoJamfCloudEnvironmentsforAPIs-020920-1503.pdf

which mentions the APBALANCEID cookie, but I discovered the Premium difference and got Jamf to tell me about AWSALB for that. Since I haven't touched api.py I'm just leaving this here.

[uurazzle]

Hi @Honestpuck,

Thanks for the information.

To be clear, this is used primarily for uploading packages to Jamf Distribution Point? Or you using it for other integrations?

Jamf Cloud hosted environments run on infrastructure that is clustered to ensure high uptime and performance. This means that interactions with Jamf Pro may be routed to various web applications, which do not directly communicate with each other. Most browsers use cookies to cache a session with the web application that they initially interact with, ensuring that future interactions from that same browser occur with the same web application. However, most tools that interact with APIs do not natively have this type of functionality built-in. Therefore, it's not uncommon 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 (1 minute by default) cluster refresh that takes place.

Common workflows that may require the use of cookies to interact with a given web application include almost all API calls that create new resources, assuming subsequent interaction with that resource is required. For example, to create a smart group via the API and then attempt to add it to the scope of a configuration profile, it's possible that the request to update the configuration profile would go to a web application other than the original one that created the smart group meaning the web application likely doesn't know that the new smart group exists yet. These are the types of issues that can be prevented by using cookies.

So, maybe log-term with the project, we might need to implement these for additional integrations out simply uploading packages like creating new resources. I would like ability to create new policies, patch management items and definitions, etc. to automate new software distributions, etc.

[Honestpuck]

You want to use a cookie any time you are doing a PUT or a POST and likely to do a GET or DELETE within a few minutes or relying on a record being present such as creating a patch version and then using that in a patch definition.

It comes up most when uploading because the current upload method can't set any other values such as category or note fields.

I'm actually getting the cookie and using it for an entire session as an autopkg "session" is only one recipe.