You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Router support for unauthenticated, gatekeeper-authenticated routes (webhooks)
#829
Some integrations need a path that the Workshop session and Cloudflare Access cannot sit in front of
(e.g. an inbound webhook or a callback from a third-party service). Today the router only exposes
gatekeepers under /gatekeeper/<name>/* behind the Workshop.
I have a ~25-line patch to packages/router/src/index.ts: an optional PUBLIC_ROUTES var (JSON [{ prefix, binding }]). A request whose path matches prefix is forwarded straight to that service
binding with no Workshop session; the target gatekeeper must authenticate each request itself, and
Cloudflare Access must be configured to bypass those paths. Unset means no behavior change.
Security notes, since this opens an unauthenticated path:
It is opt-in per deployment and only deployer-controlled config can add routes.
The route is evaluated before the GATEKEEPER_* scan, so it cannot be shadowed.
Would a mechanism like this be acceptable? If so, I'll tighten it and open a PR.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Some integrations need a path that the Workshop session and Cloudflare Access cannot sit in front of
(e.g. an inbound webhook or a callback from a third-party service). Today the router only exposes
gatekeepers under
/gatekeeper/<name>/*behind the Workshop.I have a ~25-line patch to
packages/router/src/index.ts: an optionalPUBLIC_ROUTESvar (JSON[{ prefix, binding }]). A request whose path matchesprefixis forwarded straight to that servicebinding with no Workshop session; the target gatekeeper must authenticate each request itself, and
Cloudflare Access must be configured to bypass those paths. Unset means no behavior change.
Security notes, since this opens an unauthenticated path:
GATEKEEPER_*scan, so it cannot be shadowed.Would a mechanism like this be acceptable? If so, I'll tighten it and open a PR.
All reactions