Handling Dynamically Generated Cookies with Expiry time

Load Test Q&A
#1

I have recorded a load test script (mobile_app) and see that dynamic cookie has been generated in very first URL in HTTP Request Header instead of being in HTTP Response Header. Same cookie is getting generated in HTTP Response Header in 3rd URL. Due to which I am unable to extract and assign the variable for the same and it has expiry time as well of 24 hours. If I am extracting the cookie variable and assigning it then it is showing error.

Generally we handle the variables when it gets generated first in HTTP Response Header from where we extract and assign to the URL where it gets generated in HTTP Request Header. But in this case it is getting generated first in HTTP Request Header and later in HTTP Response Header due to which we are unable to extract and assign it from there and if we do so it shows an error.

Can you please help me to understand how should I handle this dynamically generated cookie which has expiry time of 24 hours?

#2

Hello @Shailesh, the reason why you have a cookie in your first request is usually because of two things,

  1. You already had an active session when you started recording traffic with ZebraTester
  2. The application itself has a function that generates the cookie locally

Do you start the recording of the app before or after you start the application?

If you start the recording before you open the app and still get the cookie in your first request then you might have to reset your app and restart it in order to capture the authentication step that that generates the cookie.

#3

Hey @daniel thanks for the quick response. I recorded the script thrice and it is for the iOS mobile app and in all the cases cookie is getting generated in the first URL. My problem is not that it is getting generated in first URL however problem is that it is getting generated first in HTTP Request Header and then in HTTP Response Header in third URL.

Generally when I recorded the script for mobile app (Android) earlier for the same application with same end-points. Same cookie got generated first in HTTP Response Header from where we extract the variable for the same and assign to all the subsequent URLs where it has been generated. But here as the case is vice-versa and when I am extracting the variable for the cookie and assigning it to all the URLs with same cookie value an error is coming up, which looks like this:

Warning - Invalid Var Handler Usage:
Var GuestCookie assigned before extracted! Load Test execution will fail. Please correct this situation.

Note: GuestCookie is the name of cookie variable which I have provided by extracting the particular cookie.

Also this is dynamically generated cookie which expires with in 24 hours. So when I recorded the script again after 24 hours cookie is getting generated on the same URLs but with different values.

#4

Just to answer to your question, we record the scripting by clearing browser history and start the application in a fresh mode i.e. close all the apps open instances in the phone.

We start the recording first and open the app on phone later. We did the same when we were recording for Android as well and it worked fine. Now when we are doing for iOS app for the same application we are facing this issue.

I believe your 2nd point i.e. The application itself has a function that generates the cookie locally is correct.

Thank you so much for your help in advance.

#5

@Shailesh yes i think the app is doing something with the cookie here, it either generates it or it is presenting the GuestCookie from some sort of appcache, so when you start it the following flow happens

flow 1,
client app: hi this is my cookie
backend: nope, too old heres a new one

flow 2,
client app: hi this is my cookie
backend: this cookie is ok, keep it

Above is super simplifed but it sounds like something like that is happening, your app starts and presents the last valid cookie, server has invalidated it because of 24h limit and presents a new one

This can be confirmed if you wait out the 24h and then record what happens in the app, if you see 2 different GuestCookie values then it confirms the above flow, if you see GuestCookie with the same value still then we shall be confused togheter and i reccomend getting in touch with the developer then.

This also means that there might be an instance where you only have this cookie and no cookie at all presented at the start making it 3 different behaviours depending on if its a fresh, expired or current session.

flow 3
client app: hi im new
backend: here have a cookie

Hope this helps

#6

Hey @daniel Thanks for the explanation.

I tried recording the script after 24 hours and see that Guest Cookie is getting generated on the same URL in HTTP Request Header with different value.

The issue which I am facing right now is that since I have started scripting on APICA this is the first time I see guest cookie getting generated first on HTTP Request Header and then in later in HTTP Response Header instead of getting generated first on HTTP Response Header and later in HTTP Request Header.

Here is the screenshot when I tried to search the cookie:

ZebraConsole
ZebraConsole.png1863×726 66.9 KB

As usual I tried to extract the cookie variable from the URL where it has been generated for the first time in HTTP Response Header i.e. URL 3 and assigned the variable to all the other URLs with same value. By this way it is getting assigned to URL 1, 2,3,4,5 etc wherever it has been found.

After this gets assigned I see that there is an error which says:

Warning - Invalid Var Handler Usage:
Var GuestCookie assigned before extracted! Load Test execution will fail. Please correct this situation.

So, Please let me know how to handle this cookie variable.

#7

Hi Shailesh,

just to understand the application behavior better, could you please try without passing the cookie value till step 3? i.e. issue the url request, 1, 2, 3, without cookie and see if you still get the cookie in the http response header as part of url 3 ?

#8

it looks like this post has been abandoned - I will hold off on posting to the new Community for now