transformResponse decode JWT token & Save for next request

Gatling (Open-Source)
1

I am using Gatling version 3.9.2. I have a chainbuilder scenario where a specific endpoint returns a jwt token that I need to decode and use the cid value stored in that token in the next request. I was trying something along the lines of this but I only need the token in that response body decoded not the entire response. I am not finding good examples online of using transformResponse for what I am trying to do. Curious if there is a way to decode this token using .check instead. Any help is greatly appreciated! Thanks in advance.

                .exec(
                        http("POST /verification/verify")
                                .post("/verification/verify")
                                .headers(headers_10)
                                .header("authorization", token.concat("#{bearerToken}"))
                                .body(StringBody("{ \"VerificationType\": \"#####\", \"EmailAddress\": \"#{email}\", \"Token\": \"######\" , \"TransactionId\": \"#{transactionId}\"}"))
                                .check(jmesPath("token").find().saveAs("verifyToken"))
                                .check(status().is(200))
                                .transformResponse((response, session) -> {
                                            if (response.status().code() == 200) {
                                                return new io.gatling.http.response.Response(
                                                        response.request(),
                                                        response.startTimestamp(),
                                                        response.endTimestamp(),
                                                        response.status(),
                                                        response.headers(),
                                                        new io.gatling.http.response.ByteArrayResponseBody(Base64.getDecoder().decode(response.body().string()), StandardCharsets.UTF_8),
                                                        response.checksums(),
                                                        response.isHttp2()
                                                );
                                            } else {
                                                return response;
                                            }
                                        }
                                )
                )
                .pause(1);
2

Checks have a transform method.
Or you can parse your token after the request in an exec(function).

3

Thanks for your response… I am trying this

.check(jmesPath("token").transform(jwt -> JWT.decode(jwt).getClaim("cid").asString()).saveAs("customerId"))

based on this stack overflow article:

I am getting the following error:

Request 'POST /verification/verify' failed for user 2: jmesPath(token).find.transformOption.is(${customerId}) extraction crashed: c.a.j.e.JWTDecodeException: The claim 'iat' contained a non-numeric date value.

When decoding the token using jwt.io, the iat claim is:
“iat”: “3/19/2023 7:45:13 PM”.

I am not sure how to resolve this error. I know our front-end is able to parse this token successfully…

4

Hi @halley,

From the RFC:

4.1.6. “iat” (Issued At) Claim
The “iat” (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.

Either fix your authentication server, or you’ll have to use another JWT library.

Cheers!

5

Agree with @sbrevet . It seems your server’s JWT implementation violates the JWT specification.
The com.auth0:java-jwt library implements the specification strictly and rejects malformed payloads.

You can see on jwt.io’s home page a valid example of iat:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

IMHO, looking for a lenient parser is not the right solution. You should fix your server application instead.

6

Thank you both! We have removed that claim as no one in our organization is using it.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.