Skip to main content

Using Long Lasting Tokens

Legacy Documentation
You're viewing legacy documentation for API Fortress (deployed via an on-premises container). To view documentation for the new SaaS version of API Fortress — now known as Sauce Labs API Testing and Monitoring (with Sauce Connect tunnels) — see API Testing on the Sauce Labs Cloud.

It is common for an authentication system to generate long lasting tokens to perform multiple requests. In API Fortress there are many paths of authenticating that can be taken, but sometimes users prefer the token reuse strategy.

Goal​

In this example we are showing you how to allow a test to store a token for further executions, and refresh it when it’s time. Each test will need to contain this logic, and each token will be bound to the test itself.

Here’s the complete test. Have a quick look at it before proceeding to the steps:

screenshot.png

  1. Prepare the input set by adding the basePath, loginPath, and dataPath. Most importantly, add an empty variable for token and expires. These items will be updated by the test.

    1.png

  2. Add an IF component with this logic:

    !expires || D.nowMillis() > expires.toLong()
    3.png

  3. Within the IF branch, make the login call. Shown here is a call to the login URL. We are storing the retrieved information in the variable named “loginPayload."

    4.png

  4. Within the IF branch, set the value to token and expires. Note that in the value we’re saying: take the current time and add one hour

    D.plusHours(D.nowMillis(), 1)
    5-1.png 6.png

  5. Within the if branch, update the input set. This is a unique feature of API Fortress. By performing this operation, you’re having the test modify itself for the next use by updating the token and the expires variables. By doing so, the token will be available for all tests executions that will happen within an hour, and therefore no login calls will be made.

    7.png 8.png

  6. After the IF branch, perform the main call. We can reference the previously updated token.

    call-1.png

Effects​

When running outside the workbench, two subsequent test executions will look like this:

9.png 10.png

Code View​

The whole operation might seem a bit annoying to replicate in every test, but the code view and some copy and paste can ease the pain.

note

Keep in mind this is just an example, and the calls are meant to be very simple. The following is the code version of the IF branch containing the authentication logic.

<if expression="!expires || D.nowMillis()&gt;expires.toLong()">
<comment> <![CDATA[Authentication has to be performed due to expired token]]> </comment>
<post url="${basePath}${loginPath}" params="[:]" var="loginPayload" mode="json">
    <postParam name="username" value="test"/>
    <postParam name="password" value="test"/>
</post>
<set var="token" value="${loginPayload.token}" lang="java"/>
<set var="expires" value="${D.plusHours(D.nowMillis(),1)}"/>
<update-input var="token"/> <update-input var="expires"/>
</if>
Additional Notes

Updating input variables won't work when launching a test from within the composer, so the login call will run every time when developing a test. Run the test from outside the composer or schedule the test to see it in action.

Language Appendix​

  • Negation: the exclamation mark (!) prior to an expression is used as a negation and it means: when it’s false, when it’s empty, when it does not exist. In our example: !expires means when expires is empty.
  • Logic Or: the classic double pipe sign ( || ). Rarely used in API Fortress except in IF conditions.
  • toLong(): converts a string to a long number.
  • D.<action>() an API Fortress language extension that provides date and time manipulation functionalities. Please refer to the expression language extensions page for further details.