fetchdocs signs redirect URLs to prevent tampering by adding a signature to the URL. The signature is a hash of the URL, including the query parameters and a secret. The secret is your API key because it's the secret that you and fetchdocs share and that allows you to verify the signature.
For the hashing fetchdocs uses HMAC with SHA-256. This is a widely used and secure way to hash data. The hash is then encoded as a hexadecimal string and added to the URL as a query parameter.
Every signed URL carries an expires query parameter, a unix timestamp of the moment the signature stops being meaningful. It is added before the signature is calculated, so it is part of the signed data and cannot be changed or removed without breaking the signature.
You do not have to change your verification code for this: expires is an ordinary query parameter, so the recipes below pick it up automatically. In addition to verifying the signature, you should reject a URL whose expires lies in the past:
⚠️ fetchdocs only signs redirects for your own application
A URL can only be signed if it points to the same host as the
return_urlyou passed when creating the session token. Requests for any other host are rejected with a422.
To verify the signature, you need to calculate the hash of the URL and the secret and compare it to the signature in the URL. Here is an example of how to do this in some common languages:
This is an example or a proof of concept, and you should adapt it to your programming language, framework, and code style. The important thing is that you calculate the hash of the URL and the secret and compare it to the signature in the URL.
⚠️ Always validate URL signatures
You should always validate the signature of a signed URL before using its parameters. If the signature isn't valid, you shouldn't trust the URL and take appropriate action.