Using Long Lasting Tokens

Introduction
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:

  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
  2. Add an IF component with this logic:
    !expires || D.nowMillis()>expires.toLong()

    3

  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
  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 )

    56

  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 8
  6. After the IF branch, perform the main call. We can reference the previously updated token.
    call

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

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>

More 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 http://apifortress.com/doc/expression-language-extensions/ for further details.