How to restrict access to a published HTML site
Sharing ·
An internal dashboard and a client deliverable can both be HTML files, but they need different audiences. Before sending a published URL, decide whether it should be open to anyone with the address, limited to a company, or shared with specific recipients.
Publidock sets one sharing rule per site. That rule controls who can open its published content. You can change it from the dashboard as the audience changes.
Match the rule to the audience
Anyone with the link allows someone to open the site without signing in. Use it for material you are comfortable sharing openly. A long or unlisted address is still a public link once someone obtains it.
Company-domain sharing is useful for an internal report that people with an approved company email identity may read. Use the allowed domain you intend, and check it with a viewer from that company. It is broader than an explicit list of colleagues.
Named people limits access to the email addresses you choose. For a small client review, enter the recipients' intended addresses and ask them to use the corresponding identity. A person signing in with another address may correctly be denied.
Password sharing allows someone who knows the password to open the site. Set an expiry when the handoff should end. A password can be passed along, so use named people when the recipient's identity matters more than possession of a shared secret.
Company-domain and named-people sharing are Team features. Check pricing for the available rules on your plan. The sharing documentation describes the supported modes.
Set the rule before the first live publish
In Publidock's browser publishing flow, choose Who can open it, fill in the required domain, addresses or password, and inspect the preview. Select Go Live when the artifact and audience are ready. For a new site, the chosen rule is saved before the preview becomes the live version.
The underlying default for a newly created site is link sharing. API and MCP uploads can publish immediately, so configure the intended rule before uploading confidential files through those routes. Use a harmless example when testing a new publishing integration.
For an existing site, review its current rule before adding the next version. Normal updates preserve the address and rule. When the audience changes, update Who can open it too; a content refresh does not decide a new audience for you.
Test access as a recipient
Opening your own site while signed in as its owner does not prove that a client can reach it. Use a separate browser session or viewer account to check the actual rule.
- For link sharing, open the live URL while signed out.
- For a company rule, check an allowed identity and confirm an unrelated address cannot read it.
- For named people, test an invited address and check for mistakes in the saved list.
- For a password rule, check the password prompt and the saved expiry before sending the handoff.
If a viewer cannot open the site, compare their signed-in address with the rule before publishing another copy. A duplicate site can make it harder to know which address and audience are current.
Keep access control separate from the report's contents
Publidock excludes customer-published files from search indexing. That does not replace an access rule. Someone who receives a public link can still open it.
An authorized viewer also receives the data and scripts included in the files. Hiding a chart series or a page section is not a way to enforce per-person data permissions. Publish only the material that audience may receive, and keep private backend credentials out of the export.
Start with the HTML report guide to prepare the files, then publish a report and verify its audience before circulating the URL.