What are Public Applications?（什么是公共应用？）¶

A Public Application is a Foundry-hosted website paired with a constrained, allow-listed unauthenticated ontology API, both served from a Foundry subdomain. Public Applications enable developers to build internet-facing experiences directly on Foundry, without exporting data to an external hosting platform. The Public Application's end users do not log in to Foundry, so anyone who can reach the subdomain can load the website and call the small set of unauthenticated ontology operations it exposes. Foundry handles authentication on their behalf through a service user managed by the application.

:::callout{theme="neutral" title="Looking for the Slate public form upload feature?"} This page documents OSDK-based Public Applications served from Developer Console. If you are looking for the Slate-based public form upload workflow, see Upload data for public applications. :::

When to use a Public Application¶

Public Applications support workflows where the end users are members of the public who do not, and should not, have a Foundry account. Common patterns include:

One-way data collection forms: Send a link to members of the public so they can submit information, where each submission is stored in the ontology through a non-function-backed action and users do not require return access to the data they submit.
Public data dissemination dashboards: Present pre-computed aggregate views of your ontology's data and allow limited end-user interaction, such as filtering by a known dimension.
Public registration and sign-up flows: Collect interest, contact details, or registration information from a known audience without requiring those users to onboard to Foundry.
Static website landing pages: Deploy landing pages that do not require interaction with your ontology at all.

Public Application structure¶

Foundry composes a Public Application as three customer-visible parts:

Unauthenticated website: The static assets (HTML, CSS, and JavaScript) of your application are served from a Foundry subdomain without requiring a Foundry login. This is similar to a Foundry-hosted OSDK application without the login flow.
OSDK in the end user's browser: Your application uses the OSDK to make ontology calls from the user's browser, using only operations that you explicitly enable for unauthenticated access.
Unauthenticated API proxy: Each ontology call from the browser is routed through a Foundry-managed proxy that authenticates the request as the application's service user before it reaches the ontology. The end user never holds, sees, or transmits a Foundry token.

Public Applications perform every request as the application's service user, so the Public Application's resource scope configured in Developer Console and resources visible to the service user define the maximum surface area of data it can expose.

:::callout{theme="neutral"} A Public Application can be composed of only an Unauthenticated website or a combination of an Unauthenticated website and an Unauthenticated API proxy. :::

Security and protection model¶

Foundry exposes Public Applications to your enrollment's ingress policies, which may be as broad as the open internet without authentication, so Foundry applies several protections by default. Developers cannot configure these default protections, as they exist to ensure enrollment stability and limit potential abuse.

Strict allow-list of ontology operations¶

You can only call a small subset of ontology operations from a Public Application. Foundry blocks any operation at the proxy layer regardless of the calling user's permissions that triggers non-constant compute, including functions, function-backed actions, search, aggregation, and search-arounds. Review the currently supported features documentation for the full list of blocked operations.

Per-application rate limits¶

Foundry applies per-application rate limits to unauthenticated traffic before any authentication swap is performed. This protects the rest of the platform from abuse on the public internet and ensures that one application's traffic cannot exhaust the capacity of another.

Inherited ingress and Web Application Firewall (WAF) protection¶

A Public Application's subdomain inherits the ingress policy of the parent enrollment domain. If your enrollment is restricted to a specific set of regions or networks (for example, US-only), the same restrictions apply to the Public Application. All requests pass through the enrollment WAF before reaching Foundry. Foundry offers individual application ingress policy configuration to allow for Public Applications to serve broader ingress policies compared to the enrollment.

Service user identity only¶

The application runs as a service user managed by Foundry. There is no per-end-user identity in a Public Application, so Foundry cannot, for example, attribute a write back to an individual member of the public. You should not use a Public Application for workflows that require per-end-user identity. For background on service users and the client credentials grant, review the OAuth2 clients documentation.

Resource governance¶

You can only add a resource to a Public Application if you have permission to remove every Marking and Organization Marking on that resource. If you cannot, then Foundry blocks you from adding a resource to the application's scope.

This export control model ensures that resources only become reachable from the public internet through an explicit, audited decision-making process made by someone who already has the authority to lift each restriction on the data.

Learn more about Markings in Foundry.

How to mitigate risks when creating and exposing Public Applications¶

Public Applications can be configured to be reachable by anyone on the internet without authentication, so you as the application developer are responsible for implementing the risk mitigation practices outlined in the sections below in addition to the Foundry-managed protections described above.

Ensure URL identifiers are unguessable¶

Anything served by a Public Application is reachable by anyone who can access the URL and meets the enrollment's ingress policies. You should ensure that identifiers in URLs are unguessable (for example, randomly generated UUIDs). Only data that is intentionally publishable should be in scope.

Eliminate compute exposure¶

Function-driven workflows are blocked today specifically because they may expose enrollments to compute-cost attacks. If your workflow needs heavier processing, perform it asynchronously inside Foundry. As an example, configure an automation on data already written by the application rather than attempting to run it on-demand from a Public Application.

Ensure all resources exposed can be made public¶

Adding a resource to a Public Application makes the resource reachable from the public internet. You are responsible for ensuring that the resources added are intended to be public and for treating each addition as an export decision.

Approval requirements¶

Every Public Application requires a use-case review by an Information Security Officer in your enrollment before it can be enabled. The Information Security Officer is responsible for confirming that:

The intended workflow is appropriate for an internet-facing, unauthenticated surface.
The resources added to the application are intended to be reachable from the public internet.
You, as the developer, understand the risks and have designed the workflow to mitigate them.

This review occurs in addition to the standard subdomain approval that the same role performs in Control Panel as part of the Public Application setup process. Document the approved use case before requesting the subdomain so the approver has the context needed to make the decision.

Next steps¶

Now that you have an understanding of what Public Applications are and how users interact with them outside of Foundry, you can create your first Public Application and configure its subdomain.

中文翻译¶

什么是公共应用？¶

公共应用（Public Application） 是一个 Foundry 托管的网站，配有一个受限且经过白名单认证的未认证本体 API，两者均通过 Foundry 子域名提供服务。公共应用使开发者能够直接在 Foundry 上构建面向互联网的体验，而无需将数据导出到外部托管平台。公共应用的最终用户无需登录 Foundry，因此任何能够访问该子域名的人都可以加载网站并调用其暴露的少量未认证本体操作。Foundry 通过由应用管理的服务用户代表用户处理身份验证。

:::callout{theme="neutral" title="正在寻找 Slate 公共表单上传功能？"} 本文档介绍的是基于 OSDK 的公共应用，这些应用通过开发者控制台提供服务。如果您正在寻找基于 Slate 的公共表单上传工作流，请参阅为公共应用上传数据。 :::

何时使用公共应用¶

公共应用适用于最终用户是公众成员且没有（也不应有）Foundry 账户的工作流。常见模式包括：

单向数据收集表单： 向公众成员发送链接，以便他们提交信息，每次提交通过非函数支持的操作（non-function-backed action）存储在本体中，用户无需返回访问他们提交的数据。
公共数据传播仪表板： 展示本体数据的预计算聚合视图，并允许有限的最终用户交互，例如按已知维度进行筛选。
公共注册和报名流程： 从已知受众收集兴趣、联系方式或注册信息，而无需这些用户加入 Foundry。
静态网站登录页面： 部署不需要与本体交互的登录页面。

公共应用结构¶

Foundry 将公共应用组合为三个对客户可见的部分：

未认证网站： 应用的静态资源（HTML、CSS 和 JavaScript）通过 Foundry 子域名提供服务，无需 Foundry 登录。这类似于Foundry 托管的 OSDK 应用，但没有登录流程。
最终用户浏览器中的 OSDK： 您的应用使用 OSDK 从用户浏览器进行本体调用，仅使用您明确为未认证访问启用的操作。
未认证 API 代理： 来自浏览器的每个本体调用都通过 Foundry 管理的代理进行路由，该代理在请求到达本体之前将其认证为应用的服务用户。最终用户从不持有、查看或传输 Foundry 令牌。

公共应用以应用服务用户的身份执行每个请求，因此在开发者控制台中配置的公共应用资源范围以及服务用户可见的资源定义了其可以暴露的最大数据范围。

:::callout{theme="neutral"} 公共应用可以仅由未认证网站组成，也可以由未认证网站和未认证 API 代理组合而成。 :::

安全与保护模型¶

Foundry 将公共应用暴露给您的租户的入站策略，这些策略可能宽泛到无需身份验证的开放互联网，因此 Foundry 默认应用了多种保护措施。开发者无法配置这些默认保护措施，因为它们的存在是为了确保租户稳定性并限制潜在的滥用。

严格的白名单本体操作¶

您只能从公共应用调用一小部分本体操作。无论调用用户的权限如何，Foundry 都会在代理层阻止任何触发非恒定计算的操作，包括函数、函数支持的操作、搜索、聚合和搜索周边。请查阅当前支持的功能文档以获取被阻止操作的完整列表。

按应用速率限制¶

在执行任何身份验证交换之前，Foundry 会对未认证流量应用按应用速率限制。这可以保护平台的其他部分免受公共互联网上的滥用，并确保一个应用的流量不会耗尽另一个应用的容量。

继承的入站策略和 Web 应用防火墙（WAF）保护¶

公共应用的子域名继承父级租户域名的入站策略。如果您的租户仅限于特定区域或网络（例如仅限美国），则相同的限制也适用于公共应用。所有请求在到达 Foundry 之前都会通过租户 WAF。Foundry 提供单独的应用入站策略配置，以允许公共应用服务于比租户更宽泛的入站策略。

仅限服务用户身份¶

应用以 Foundry 管理的服务用户身份运行。公共应用中没有每个最终用户的身份，因此 Foundry 无法将写回操作归因于某个特定的公众成员。您不应将公共应用用于需要每个最终用户身份的工作流。有关服务用户和客户端凭证授权的背景信息，请查阅 OAuth2 客户端文档。

资源治理¶

只有拥有移除资源上每个标记（Marking）和组织标记（Organization Marking）权限时，您才能将资源添加到公共应用。如果您没有这些权限，Foundry 将阻止您将资源添加到应用的范围中。

这种导出控制模型确保资源只有通过已经有权解除数据上每个限制的人员做出明确且经过审计的决策后，才能从公共互联网访问。

了解更多关于 Foundry 中标记的信息。

如何降低创建和暴露公共应用时的风险¶

公共应用可以配置为允许互联网上的任何人无需身份验证即可访问，因此作为应用开发者，您有责任实施以下各节概述的风险缓解实践，此外还要实施上述 Foundry 管理的保护措施。

确保 URL 标识符不可猜测¶

公共应用提供的任何内容都可以被任何能够访问 URL 且满足租户入站策略的人访问。您应确保 URL 中的标识符不可猜测（例如，随机生成的 UUID）。只有有意公开的数据才应纳入范围。

消除计算暴露¶

函数驱动的工作流目前被阻止，正是因为它们可能使租户面临计算成本攻击。如果您的工作流需要更重的处理，请在 Foundry 内部异步执行。例如，在应用已写入的数据上配置自动化，而不是尝试从公共应用按需运行。

确保所有暴露的资源都可以公开¶

将资源添加到公共应用会使该资源可从公共互联网访问。您有责任确保添加的资源是旨在公开的，并将每次添加视为导出决策。

审批要求¶

每个公共应用在启用之前都需要由您租户中的信息安全官（Information Security Officer） 进行用例审查。信息安全官负责确认：

预期的工作流适合面向互联网、未认证的表面。
添加到应用的资源是旨在从公共互联网访问的。
作为开发者，您理解风险并已设计工作流以缓解这些风险。

此审查此外还补充了同一角色在控制面板中作为公共应用设置流程一部分执行的标准子域名审批。在请求子域名之前记录批准的用例，以便审批人拥有做出决策所需的上下文。

后续步骤¶

现在您已经了解了什么是公共应用以及用户如何在 Foundry 之外与之交互，您可以创建您的第一个公共应用并配置其子域名。