Passing Dynamic Tokens in the API Header

Osmos does not support passing dynamic tokens in the header for API connector. This page outlines an alternative approach to achieve the same outcome.

Approach

  1. Store key as an environment config on the server side

  2. Pass user and/or Org specific things (not secrets) as Param fields. e.g.

  3. Host the following example code (with necessary modifications). This example is a fully dockerized, ready to deploy server that you can put into Lambda/cloud run).

  4. Fetch the secret. from the "environement" the server process is running. e.g. api_key = os.environ.get("MY_SECRET_API_KEY")

  5. Add that to the header on line 34 of the code snippet below

  6. Point Osmos API destination connector at this endpoint.

  7. This endpoint receives the request, manipulates it to move param fields into Header/URLquery params and inject things like dynamic auth tokens etc. before making a downstream request to the your final API

Configuring

Below is an example to turn JSON properties in the inbound request into query parameters for the outbound request.

Osmos's HTTP API Destination connector should set the following headers (example data shown), with batching disabled:

  x-Osmos-Outbound-Url: https://httpbin.org/post
  x-Osmos-Query-Param-Fields: queryparam1,queryparam2

Here, queryparam1 and queryparam2 are any fields in the Osmos Connector schema. When using an Uploader, these can be set to be parameterized fields. Then, these fields can be set to constant values in the browser JS (eg: user id, session id, etc) and Osmos + this web server will send these values as query parameters instead.

Osmos will then make outbound requests with payloads in them that look like below:

{
  foo: 'dfoo',
  bar: 'dbar',
  baz: 'dbaz',
  queryparam1: 'dqp1',
  queryparam2: 'dqp2'
}

It will make an outbound request to https://httpbin.org/post?queryparam1=dqp1&queryparam2=dqp2& with payload

{
    "foo":"dfoo",
    "bar":"dbar",
    "baz":"dbaz"
}

Sample Server

This example is a fully dockerized, ready-to-deploy server that you can put into Lambda/cloud run. You then point to the Osmos API Destination Connector. It receives the request, it can manipulate it to move param fields into header/URL query params and inject things like dynamic auth tokens etc. before making a downstream request to the customer API.

You can also easily reshape the output from Osmos into nested JSON .

How to invalidate the session token

Option 1 (preferred):

  1. Send the session token as a param field to a Dataset Table rows

  2. Discard rows with invalid tokens

Option 2:

  1. Send the session token via param fields

  2. Validate it in this example server above. This allows you to remove at any time.

Last updated