Skip to main content
A CDN stage runs one FastEdge application. An authorization check and a label check for the same stage belong in that one handler, and the CDN resource stores one application id for the stage. Complete the CDN setup before building the handler. Attach the deployed application with CDN applications.

Write both checks in one handler

Replace src/lib.rs in the my_cdn_app project from the CDN setup. The handler returns HTTP 401 when x-auth is not allow, HTTP 403 when x-label is missing, and HTTP 200 when x-auth is allow and x-label has a value.

Build the binary

Build with the same target as the CDN setup.
The binary is target/wasm32-wasip1/release/my_cdn_app.wasm.

Deploy the application

Upload my_cdn_app.wasm with the CDN deploy steps and attach that one application to the stage. The calls below create the application and store one application id on on_request_headers. All requests authenticate with an API token. Set it as an environment variable before running the commands:

Step 1. Upload the binary

The response id is the binary for the next call.
The API returns:

Step 2. Create the application

Setting status to 1 enables the application.
The API returns:

Step 3. Attach the application

Store the application id as one string on on_request_headers.
A list of application ids is rejected. The API returns HTTP 400:

Check both behaviors

Request the CDN hostname with no x-auth header, and the application returns HTTP 401 and the body auth-rejected. Send x-auth: allow and no x-label, and the application returns HTTP 403 and the body label-rejected. Send x-auth: allow and x-label: beta, and the application returns HTTP 200 and the body labeled beta. After an earlier binary update, one edge served the previous binary on the first request and these checks on the next request.