Public Access

Overview

Public access content refers to interactive content that is available to anyone on the internet, without requiring a login.

To enable public access (“Anyone - no login required”, all) for interactive content (e.g. Shiny applications, FastAPI APIs), you must have an Enhanced or Advanced license with the Public Access entitlement. Without this entitlement, interactive content is restricted to the “All users - login required” (logged_in) and “Specific users or groups” (acl) access types. Speak to your Posit Customer Success contact or email upgrade@posit.co for more information about a license which allows Public Access.

Posit Connect periodically verifies that content set to public access is actually available on the public internet.

Note

If you own or have been approved to test a license that entitles you to unrestricted public access, the Advanced Unrestricted license type includes the Public Access entitlement, without requiring the public URL verification described below. This license allows you to share content with anonymous users on an internal or private network.

If there are questions about your license or license entitlement please contact your Posit account team.

Public access content verification

Public Access content must be available on the public internet. When you use the “Anyone - no login required” access type to host public content, Posit Connect will verify that the content is publicly available online by reaching out to a Posit server at regular intervals.

Note

When using Posit Connect with a license that enables Public Access, but does not include Unrestricted access, the following must be configured:

• Connect must have outbound access to the URL validation server, which is located at https://verify.pct.posit.co/url-validator using port 443.
• The X-Content-Signature and Date headers must not be edited or removed from HTTP requests or responses by any proxies as they are required when communicating to the URL validation server.
• Connect’s configuration setting Server.Address must specify the server’s publicly-accessible URL.
• Content set to public access must be available on the public internet.

If there are questions about your license or license entitlement please contact your Posit account team.

Verification begins when a content item first uses the “Anyone - no login required” access type on a version of Connect supporting Public Access. Connect will periodically check the URL of the content item to verify it is publicly accessible.

The verification process allows for occasional network failures or temporary configuration issues and does not display a warning message in the dashboard if verification fails a few times (each failure is logged; see below). After an initial grace period, if Connect is unable to verify public access, the Connect dashboard access settings for the affected content displays a warning message. If verification problems continue, content is restricted to the “All users - login required” access type, and anonymous access to the content is prohibited.

Connect logs a warning each time a content item fails verification. Check your server logs for messages like this:

time="2024-09-25T13:51:33.458Z" level=warning msg="Content is configured for public access, but Connect failed to validate its public availability (checked at 2024-09-25 13:51:33 +0000 UTC)" content_guid=47f772c7-133a-4ad0-95db-b69f067d12cd

Connect also logs a message each time a user attempts to access a content item that has failed verification and become restricted to logged-in users only. Check your server logs for messages like this:

time="2024-09-25T13:51:33.458Z" level=info msg="restricting public access to app" err="<nil>" guid=47f772c7-133a-4ad0-95db-b69f067d12cd status=restricted

If content on your Posit Connect server has failed verification, your server’s network configuration may need adjusting. Please contact Posit customer support for assistance (support@posit.co).

Public Access content verification is designed to validate compliance with Posit EULA and SLD terms through the transmission of a minimal data packet.

We do not transmit any user data.

The only data sent from a customer server to Posit includes:

• the license key for Posit Connect,
• the current product (Posit Connect) version,
• and a list of public access interactive content, which includes: the content GUID, content type (e.g., Shiny, Plumber API), and the public URL.

Illustrated workflow and common issues

Connect periodically sends a list of public, interactive content URLs to the verification service. The service uses remote workers to verify that each content URL is accessible on the public internet, and replies to Connect with a list of statuses. Requests and responses are signed to prevent tampering.

graph LR
    accTitle: Connect sends a request to verify public access URLs
    accDescr {
        Connect sends a request to verify.pct.posit.co containing a Date header,
        an X-Content-Signature header, and a list of public content URLs.
        verify.pct.posit.co responds with a Date header, an X-Content-Signature
        header, and a list of statuses.
    }

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph connect [Connect]
        direction LR
        app1(public app 1):::public
        app2(public app 2):::public
        app3(internal app 3):::internal
    end

    connect --"`
        Date: ...
        X-Content-Signature: ...
        [app1 and app2 URLs]
        `"-->verify
    verify -."`
        Date: ...
        X-Content-Signature: ...
        [app1 and app2 status]
        `".->connect

    style connect fill:#FFF
    style verify fill:#FFF

The remote access verification workers try to load each public, interactive content item using the provided URL. The worker is simulating a member of the public trying to access your content. Each item is checked independently, so it is possible for some items to pass verification and others to fail.

graph RL
    accTitle: Remote workers verify public access URLs
    accDescr {
        Remote workers connect to individual public apps to verify their
        availability.
        They receive 200 OK responses from the public apps.
    }

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph connect [Connect]
        direction LR
        app1(public app 1):::public
        app2(public app 2):::public
        app3(internal app 3):::internal
    end

    workers --"`
        mycompany.com/app1
        `"-->app1
    app1 -."`
        200 OK
        `".->workers
    workers --"`
        mycompany.com/app2
        `"-->app2
    app2 -."`
        200 OK
        `".->workers

    style connect fill:#FFF
    style verify fill:#FFF

If verification fails, check your server logs for error messages or manually trigger a verification test as described in the User Guide and look for one of these common issues:

Connect cannot reach verify.pct.posit.co

Sometimes, validation fails because Posit Connect cannot reach the verification service at all. This may be due to a firewall, incorrectly configured proxy, or other networking issues. Connect must be able to send network requests to https://verify.pct.posit.co.

Example error messages:

"Error calling validation API: Post \"https://verify.pct.posit.co/url-validator\": net/http: TLS handshake timeout"

"Error calling validation API: Post \"https://verify.pct.posit.co/url-validator\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

graph LR
    accTitle: Connect sends a verification request which is blocked by a firewall or proxy
    accDescr {
        Connect sends a request to verify.pct.posit.co.
        A firewall or proxy blocks the request.
    }

    f[firewall/proxy]:::firewall

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph connect [Connect]
        direction LR
        app1(public app 1):::public
        app2(public app 2):::public
        app3(internal app 3):::internal
    end

    connect --"`
        Date: ...
        X-Content-Signature: ...
        [app1 and app2 URLs]
        `"--xf
    f ~~~ verify

   style connect fill:#FFF
   style verify fill:#FFF

Headers are modified or removed by a proxy

Sometimes, validation fails because a proxy or other network component removes or modifies the Date or X-Content-Signature headers, on outgoing or incoming requests or responses. These headers must be passed through unmodified.

Example error message:

"error validating public interactive content: Received error from validation server: 401 Unauthorized: request signature check failed"

graph LR
    accTitle: Connect sends a verification request which is modified by a firewall or proxy
    accDescr {
        Connect sends a request to verify.pct.posit.co containing Date and
        X-Content-Signature headers.
        verify.pct.posit.co responds with Date and X-Content-Signature headers.
        A firewall or proxy modifies or removes headers from the request or the
        response.
    }

    f[firewall/proxy]:::firewall

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph connect [Connect]
        direction LR
        app1(public app 1):::public
        app2(public app 2):::public
        app3(internal app 3):::internal
    end

    connect --"`
        Date: ...
        X-Content-Signature: ...
        [app1 and app2 URLs]
        `"--> f
    f --"`
        Date: [missing/changed]
        X-Content-Signature: [missing/changed]
        [app1 and app2 URLs]
        `"-->verify
    verify -."`
        Date: ...
        X-Content-Signature: ...
        [app1 and app2 status]
        `".-> f
    f -."`
        Date: [missing/changed]
        X-Content-Signature: [missing/changed]
        [app1 and app2 status]
        `".->connect

   style connect fill:#FFF
   style verify fill:#FFF

Content URL not reachable on public internet

Posit Connect may successfully contact the verification service, but verification may fail because the content URL is not publicly available.

Example error messages:

"Content is configured for public access, but Connect failed to validate its public availability (checked at 2025-12-12 18:17:58 +0000 UTC)" content_guid=dfcf2a19-7d4c-49c0-93bc-7d0acd6ad3d1

"content is not publicly accessible"

Internal Server.Address

Your Posit Connect instance may be configured with an internal Server.Address that is not publicly reachable.

graph LR
    accTitle: Remote workers cannot find internal apps
    accDescr {
        Remote workers try to reach internal apps to verify their availability.
        They receive a 404 Not Found response for the internal server address.
    }

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph connect [Connect]
        direction LR
        app1(public app 1):::public
        app2(public app 2):::public
        app3(internal app 3):::internal
    end

    workers --"`
        internal-server-address/app1
        `"-->dns
    dns -."`
        404 Not Found
        `".->workers

    connect ~~~ dns ~~~ verify

    style connect fill:#FFF
    style verify fill:#FFF

Restricted access to content

Your Posit Connect instance may be deployed behind a VPC or firewall requiring a login. Such content is not considered publicly available.

graph LR
    accTitle: Remote workers are blocked from accessing public apps by a VPC.
    accDescr {
        Remote workers try to reach public apps to verify their availability.
        They receive a 403 Forbidden response from the VPC guarding the apps.
    }

    subgraph verify [verify.pct.posit.co]
        workers{"`
            remote access
            verification
            workers
            `"}:::verification
    end

    subgraph vpc [VPC]
        subgraph connect [Connect]
            direction LR
            app1(public app 1):::public
            app2(public app 2):::public
            app3(internal app 3):::internal
        end
    end

    workers --"`
        mycompany.com/app1
        `"-->vpc
    vpc -."`
        403 Forbidden
        `".->workers


    style connect fill:#FFF
    style verify fill:#FFF
    style vpc fill:#D44000,color:#FFF