Skip to main content

Preview URLs

Introduction​

For collaboration and for running automated tests, you can use Preview Endpoints to access your sandboxed versions of services. Preview Endpoints provide an authenticated URL that points to a service accessible from your Kubernetes cluster.

Preview Endpoints automatically set the routing-key header context on every request made through them, so they will automatically follow the correct routing within the cluster as long as header propagation is implemented. All preview endpoints are authenticated and require a Signadot API Key or cookie-based authentication to access.

Preview Endpoint Targets​

Preview endpoints are associated with Route Groups. Each sandbox has a default Route Group that it belongs to, and that is one location where a preview endpoint can be defined, as shown below:

name: "some-sandbox"
spec:
  cluster: ...
  defaultRouteGroup:
    endpoints:
    - name: frontend-endpoint
      target: http://frontend.hotrod.svc:8080

Similarly, endpoints can also be specified in a standalone Route Group. Preview Endpoints accept a name and a target. The target refers to some in-cluster location that the URL points to.

Preview URLs associated with a Sandbox / Route Group call the target as specified, except that they set different routing key headers on each request made via the URL automatically. For example, if the target for an endpoint is frontend.hotrod.svc:8080 as shown above, any call that we make to the corresponding generated Preview URL will directly send its request to that URL, with additional headers set for the "routing key".

For this request to be re-routed to use sandboxed versions of services as it traverses different microservices in your cluster, in-cluster routing must be set up, for the appropriate local routing decision to be taken to a sandboxed workload. In the absence of a valid in-cluster routing setup, the requests may be set to the baseline service.

Accessing a Preview URL​

Preview URLs are hosted by the Signadot Control Plane and are authenticated and secured using SSL. To access a preview URL, you can do one of the following:

Access using a browser

If you're logged into app.signadot.com, preview URLs are automatically also authorized and you can access them via the browser. This is most convenient when previewing a frontend or HTTP microservice.

Access programmatically / using cURL or equivalent

To access in these ways, you must set an authentication header. This header is a special one called signadot-api-key and its value must be set to a valid API key that is generated using app.signadot.com. An example cURL request looks like the following:

curl -H 'signadot-api-key: ...'
'https://frontend-endpoint--sandbox-better-route.preview.signadot.com'

Note that you can also access the equivalent gRPC URL as well, by specifying the same header as header metadata.

Limitations of Preview Endpoints​

Preview endpoints have certain limitations that users should be aware of:

  1. CORS Issues: When accessing preview endpoints directly from a frontend application, you may encounter Cross-Origin Resource Sharing (CORS) issues which may affect certain flows or need special CORS configuration for preview URLs.

  2. Header Injection: The preview endpoints only inject the necessary routing headers on direct URL access. If your application loads additional resources or makes further requests, these requests will not have the routing headers automatically injected.

In cases where these limitations impact your workflow, it is advisable to inject the necessary headers and use existing application URLs. For web applications, this can be achieved using the Signadot Browser Extension, while mobile applications should be configured to inject the header into API requests. This approach ensures seamless routing and testing within your application environment.