OAuth2 token from response

Hello all,

I need to authenticate before making a GET request on a service, as such I have the following (Gatling 2.1.4):

val auth_token = scenario(“POST request to authenticate”)

            http("POST auth request")
                .headers("Content-Type", "application/x-www-form-urlencoded")
                .formParam("grant_type", "*")
                .formParam("userName", "*")
                .formParam("password", "*")
                .formParam("client_id", "*")

Which I can see from the server console output is authenticating correctly, I just don't know Scala / Gatling DSL well enough to parse the response into a variable that I can reference in a subsequent GET request?

(If I hit the server with Postman I get a raw response of something equivalent to "2b3c8573-f001-42e1-8ae8-30c0099cd87c" so just a String token.)

Any help greatly appreciated. Kind regards, Andrew

Definitely check out the documentation on checks: http://gatling.io/docs/2.1.4/http/http_check.html?highlight=checks

Not sure what kind OAuth implementation you’re hitting, but if you can get JSON back, you could do something like
which saves whatever’s at “token” to the session attribute “accessToken”.

In any case you’re most likely looking for

Thanks Andrew, tried that, but couldn’t work out how do I then access the variable it if it’s a session attribute? I want to make a subsequent GET request with the attribute set in the header.

Thanks, Andrew

The session is usually available in Gatling DSL methods. For example, header takes a String, Expression[String]. An Expression[String] is a type alias for Session => String.

In your case, something like

.header(“key”, “${value}”)

would set header “key” to the session attribute mapped with “value”. The “${value}” is a Gatling shortcut for basically evaluating a session attribute. It’s the equivalent to

session => session(“value”).as[String] (or possibly using Option/Validation)

Though it all seems like gibberish now, keep going through the docs

it’ll eventually start to click.

ok, thanks Andrew, that’s basically exactly what I had but it wasn’t resolving it.
i had the POST followed by the GET as separate scenarios (as opposed to chained .exec calls) so wonder if that was the problem perhaps?
good to know i’m on the right track at least…
if i still can’t get it resolved i will post the full code base with both requests to see if that helps.

thanks again, Andrew

If your request are split over several scenarios, they won’t be part of the same user “flow”, and won’t share the user’s session.
This is why the value you saved with your check was not available to the other request.

Thanks Pierre, that was my suspicion, I’ll try again with chained .exec calls and hope that resolves the problem!
Kind regards, Andrew

Thanks Andrew and Pierre.

Chaining the .exec(…) calls together in the same scenario meant the .saveAs(…) attribute was then session scoped and available within the scenario. Problem solved! :slight_smile:

Kind regards, Andrew