Hosted page protection

Protection limits reopening a page through a direct address visible in its HTML, and controls staff access to source files. An admitted visitor's browser still receives HTML, images and scripts and can save them. Content already shown in a browser cannot be made impossible to copy.

Direct links and preview

An admitted visit receives a limited access session with a cookie. In strict mode, a copied address without that cookie cannot open the page. Access is bound to the domain and page and lasts up to 24 hours. Starting with release 0.1.0-beta.20261102.1, a preview also lasts up to 24 hours; in earlier versions, up to 5 minutes. Preview requires a traffic domain separate from the panel domain.

The File access («Доступ к файлам») window opens from the More («Ещё») menu above the page's file editor; before release 0.1.0-beta.20261102.1, with a separate button there. In File access, browser resources are allowed by default, while configuration files, backup files and journals are closed. ZIP archives and uncommon files must be allowed explicitly. Check the result through a campaign link as well as in the editor.

Revoke visits («Отозвать посещения») closes previously issued access to that page. Use it deliberately: an already open form also loses access.

Starting with release 0.1.0-beta.20261102.1, a staff member's preview closes at once when they lose access to the page: when their permissions are saved, when their role or login changes, when the staff member is deleted, and when the access granted to them for an offer or landing page is removed. Visitor visits and other staff members' previews stay open. Details are in 24-hour preview of a protected page. In earlier versions, a permission change did not revoke an issued preview; it remained valid until expiry.

Staff permissions

In the Permissions («Права») window of Team («Команда»), on the Pages («Страницы») tab under Landing and offer files («Файлы лендингов и офферов»), there are five separate settings:

Values are Role default («По роли»), Authorized («Разрешено») and Denied («Запрещено»). Buyers receive preview by default within the pages they can access. Team leads and designers receive all five capabilities by default; owners and admins retain full access. Section and page restrictions still apply.

You can allow a buyer to read source files while denying edits and ZIP downloads. Denying source also denies editing, ZIP and copying. Selecting a page in a stream does not require source access.

For an offer with PHP with network access («PHP с доступом в сеть»), only owners, admins and designers may change any files: an include file can also affect PHP execution. An editing override does not remove this restriction.

An open form after a page change

A protected visit uses one complete version: HTML, PHP, include files, handlers, resources and file access settings. Saving switches new visits to the new version; an already open form keeps using the previous version even if its handler was removed from the new one.

Old snapshots remain for at least 25 hours after leaving publication; the active snapshot is retained. This is separate from the ten editor versions. Deleting a page or revoking visits closes access; recreating the same ID does not restore it.

This applies to protected visits. Old direct links in compatibility mode do not gain a pinned version retroactively. External receiver failures, visit expiry or explicit recovery after PHP state loss can prevent submission. Recovery invalidates old forms and does not repeat a POST.

Protected visits use isolated PHP sessions in private pools, while old forms use the preserved running legacy pools. A pinned file version does not migrate a session, and switching PHP pools does not transfer its state. An old unbound URL cannot reconstruct an earlier snapshot or the historical PHP with network access setting. Check the actual installation before activation: PHP sessions and temporary files.

Form data and leads.php

Micator no longer creates or appends its own form-data journals. The old POST /api/v1/lead-file returns 200 ok without reading the body or storing data. This response supports older pages and does not confirm delivery to an affiliate network.

Only old journals with the exact Micator signature are removed from working directories and excluded from copying. A custom PHP handler named leads.php remains a page file. Original archives and backups are not purged by this operation.

The /api/v1/lead contract, analytics, CAPI and postbacks remain. If your own PHP writes data to a file or sends it to a receiver, that is separate handler behavior. This change does not remove all personal data from every integration.

Review before publication

Before saving, uploading, copying or restoring, the candidate files are checked. Findings open Review before publication («Проверка перед публикацией»), showing the rule, path, line and external host. Secret values, form data and code snippets are excluded.

1. Review the findings and the purpose of external addresses.
2. Choose Cancel («Отмена») to leave the current publication unchanged.
3. If the changes are expected, choose Reviewed — publish changes («Проверил изменения — опубликовать»).

Approval covers only the reviewed files. Changed files require another review. Static analysis does not execute PHP/JS or remove code automatically. Computed addresses, code files larger than 3 MiB or more than 200 findings are marked as an incomplete review. No findings is not a guarantee of safety.

Since release 0.1.0-beta.20261103.1, the review warns about an offer link in a tag the browser loads on its own: “Offer link in a tag the browser loads on its own (<link>, <img>, <script>…). Every page view would count as a click to the offer. Use {offer} only in <a href> or a form action.” («Ссылка на оффер в теге, который браузер загружает сам (<link>, <img>, <script>…). Каждый показ страницы засчитывался бы как переход на оффер. Используйте {offer} только в <a href> или action формы.») The finding shows the HTML or PHP file and the line of the first such place in it. It appears when an address starts with {offer}, {to} or {offer:ID} (in href, also with /?_lp=1) in tags such as <link rel="stylesheet">, <img>, <script src>, <video> or in CSS url(). The review does not warn about <a> links, forms, <iframe> and meta refresh: these are click-throughs.

Move the link to <a href> or a form action, check the other offer links in that file and save the page again. If you publish as is, the tracker does not count such a load as a click-through, but in old browsers every page view becomes an LP click. The review does not find every such place — the rules are in Where to put the click-through link. Keitaro migration also requires approving this finding; the wizard and terminal report call it offer-link-autoload.

Keitaro migration requires the same review before publishing pages. If it stops with PAGE_REVIEW_REQUIRED, inspect the wizard report. In a terminal, micatorctl keitaro-import --step status shows the approval command with the exact hash. After approving, repeat the original installation command or continue in the wizard. The archive does not need to be extracted again.

Diagnostics

The Diagnostics («Диагностика») button is in the row of a hosted landing page or offer, and in the file editor it is in the More («Ещё») menu; before release 0.1.0-beta.20261102.1, it was a separate button above the editor. Diagnostics shows the protection mode, transition deadline, version readiness and counters for the last 24 hourly intervals: page and form responses, PHP errors, expired or revoked visits, missing cookies and unavailable versions.

Phone numbers, names, email addresses, IPs, click IDs, cookies, request addresses and form bodies are excluded from these counters. Raw PHP messages containing form data are suppressed in the service log. Storage failures may lose some events; the interface reports unavailability. A successful HTTP response does not by itself prove acceptance by an external receiver.

If protected access to the selected hosted page is unavailable on a campaign-link visit, the tracker returns 503. The incoming click, campaign, stream and calculated cost are retained; a click with that error is not assigned to the undelivered landing page or offer. Denied access to a hosted offer on a /clk transition records no new LP click. This accounting rule does not bypass protection or resubmit a form: metrics and cost when delivery fails.

Activation and checks

Updating retains compat mode. Separate activation after checking every instance schedules the transition in 5 minutes; direct paths and POSTs without a protected visit remain for another 48 hours before strict begins. Such a POST, including a return to the campaign link, retains the old public contract; it does not prove that the tab was opened earlier. After the transition starts, new GET visits and protected requests use private pools. Repeated activation or restarts do not extend the window. A request admitted before the deadline may finish afterwards; a new request to an old path is denied in strict.

The installation service checks the retained binding to running PHP pools and readiness before activation. Once the immutable plan exists, including its five-minute pending stage, updates and rollbacks require compatible versions that preserve the pinned PHP runtime. Rolling back to an old application without transition support and restoring any backup over this installation are blocked. Moving the clock backwards does not remove the block. Before a plan or any recovery exists, the controller may permit returning to the previous version if the pool bindings remain intact. After recovery, the old incompatible application and in-place restore remain blocked even without an arm plan. Activation confirmation requirements still apply.

Before activation, the server administrator must check all application instances, both PHP modes, the shared page directory, HTTPS, CDN/cache behavior and direct origin access. Installation service readiness does not confirm these external conditions. Stop old application processes that can write journals, then start the new admin again to remove any remaining journal; the pinned PHP pools keep running.

With the new Go application, lost, damaged or forged PHP state blocks execution before the handler without retrying a POST. Pool validation may return 503; an old or invalid protected visit may return 404. Legacy pools receive runtime restart policy no without recreation: after an OS restart, old Go must not serve an empty session. Lost data is not restored automatically. Recovery — the owner's manual php-recover or automatic recovery after a verified server restart — creates a new PHP generation and permanently retires legacy pools; previous grants and forms become invalid. A fresh campaign GET receives a protected visit even in compat, while a direct GET to an old PHP path is not upgraded. Original transition dates remain unchanged: PHP recovery and completion checks.

Using a test receiver, check campaign entry, images and scripts, landing-to-offer navigation, a regular form and handler response, and a previously open form after a page change. A POST return from another site requires HTTPS. After the transition ends, verify direct-link denial in a separate browser profile. Bundle acceptance does not replace checking the actual installation, its LB/CDN and external handlers.

The server administrator runs redirect hosted-access status and redirect hosted-access preflight inside the installation's active admin container with its normal environment. The first activation requires a successful preflight. The separate confirmed retry of an already started arm is described below. After checking all requirements, run:

redirect hosted-access arm \
  --confirm-serving-inventory \
  --confirm-https-cache-bypass \
  --confirm-restore-floor \
  --confirm-php-protocol
redirect hosted-access status

All four flags are required: they confirm operator checks that heartbeat data cannot replace. Before the first shared write, the root controller pins the original immutable plan. Save start, legacy_until and the ID from status. The local copy, Redis and commit marker must match this plan. During intermediate writes, a request may wait up to 2 seconds; without a consistent set, delivery stays closed rather than returning to compat.

Repeating the same arm command with all four confirmations can repair only an incomplete public projection of the already pinned root plan. It retains the same PHP epoch and plan, preserves healthy sessions and creates no new dates. Ordinary status only reads state and repairs nothing. This does not restore lost or conflicting Redis/local copies. Do not delete service records or run php-recover instead: recovery explicitly accepts session loss. Ask support to investigate inconsistent original copies.

Separately prepared changes: automatic cleanup and report time zones.