Skip to main content

HTTP shares

HTTP shares let you expose HTTP/HTTPS applications through a Frontdoor-managed endpoint without opening inbound firewall ports. The Frontdoor terminates TLS at the edge and securely proxies requests to your private target service. You can optionally require user authentication (for example, OAuth) before requests reach your backend.

Key concepts

  • Frontend binding: you select a Frontend (NetFoundry hosted or custom) for the share's public hostname. Requests to those Frontends are routed to your target.
  • Target: the internal URL your service listens on, e.g., http://backend.svc.cluster.local:8080 or https://app.internal.local.
  • TLS termination at the edge: client HTTPS connections terminate at Frontdoor. Backend connections to https:// targets are validated unless you explicitly mark them as insecure.
  • Optional authentication: attach an Auth Provider to enforce OAuth-based access control with optional email-domain filters.

Prerequisites

  • At least one Frontend available and, if using a custom domain, DNS pointing to the Frontend.
  • An online Agent connected to the target Environment to route traffic to your backend.
  • If using OAuth/authentication, create the Auth Provider first so you can reference its id.

Request fields specific to HTTP

  • type: "http"
  • frontendIds (required): a Frontend id to bind this share to
  • target (required): your private service URL, e.g., http://backend.svc.cluster.local:8080
  • authProviderId (optional): id of an Auth Provider to require OAuth sign-in
  • oauthEmailDomains (optional): allowed email domains for authenticated users
  • oauthAuthorizationCheckInterval (optional): ISO-8601 duration for re-checking authorization, e.g., "PT15M"
  • insecure (optional): true to skip TLS certificate verification when proxying to an HTTPS target (use only for trusted, internal, self-signed backends)
note
  • insecure affects only backend verification to your https:// target. Client-to-Frontdoor traffic remains fully validated TLS.
  • Email domain filtering applies only when authProviderId is set.

Example A: Public HTTP share

Create a simple public share bound to a Frontend, targeting an internal HTTP service:

curl -s -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "http",
"name": "publicdemo",
"envZId": "ijcrWb-ZOq",
"frontendIds": [ "bMTHPrtQ" ],
"target": "http://backend.svc.cluster.local:8080"
}' \
"https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

Example B: OAuth-protected HTTP share

Require sign-in via an existing Auth Provider and allow only specific email domains. This example also shows how to allow an internal HTTPS target with a self-signed certificate:

curl -s -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "http",
"name": "portal",
"envZId": "ijcrWb-ZOq",
"frontendIds": [ "dKRfL_UMa8DAP7KmYOdOr" ],
"target": "https://portal.internal.local",
"authProviderId": "ap_123456",
"oauthEmailDomains": [ "example.com", "subsidiary.example" ],
"oauthAuthorizationCheckInterval": "PT15M",
"insecure": true
}' \
"https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"