To avoid abuse, production ILSA instances are restricted to requests from allowed domains. This is like CORS, but the implementation is different.
In the backoffice you need to configure on which domain(s) your website is serving visitors. Requests from other domains are blocked to prevent misuse of your data.
In the Backoffice you can configure a list of IP addresses that are exempt from CORS checking. This is convenient for development environments.
IP ranges are configured in CIDR notation. Use 192.0.2.1/32 for only 192.0.2.1. Use 192.0.2.0/24 for 192.0.2.0 through 192.0.2.255. Use /128 for a single IPv6 address.
Requests from development IP addresses are also not included in the statistics, for example the number of views on each vehicle.
Usually all vehicle data in ILSA is public and calls are ideally made directly by the visitors browser, so authentication is usually not a thing. If your site is different (for example if you show trade prices), we can configure ILSA to require authentication for each call.
Using a static token works well if all requests are made by your server, but probably not great when requests are made by visitors directly. Once they have the token, they have it forever. If you’re letting your visitors make calls directly to ILSA, use short-lived tokens. We use the JWT standard.
To get a short-lived token, make a call (from your server) to /create_jwt to get a token that’s valid for 5 minutes. Pass the response in the Authorization header as a Bearer token.
If you’re using short lived JWTs, you have to handle the fact that they expire. People can keep their browser tabs open forever, so you have to automatically refresh the JWT. Do refresh them timely before they might expire.
We recommend having the browser request a new token every 4 minutes by calling your server with their account information. Your server then calls /create_jwt to create a new token that’s valid for 5 minutes. Your server can check whether their account is still active for example.