AI blog · DotApp PHP Framework 2.0

How DotApp PHP Framework protects the browser-to-PHP channel

Shop pages that save a contact form, toggle a row, or call a named PHP function do not send a naked POST. The browser talks to PHP on an encrypted, session-bound channel: generated client script, per-form binding, integrity check, then your handler. This article explains the mechanism in words. Copy-paste forms live in How to create secure forms in DotApp PHP Framework. Choosing fo-rm versus load() versus Bridge is Secure backend-frontend communication in DotApp PHP Framework.

Common mistakes

What the channel is

The browser-to-PHP channel is the path every Shop UI mutation should take: a contact save, a stock toggle, a Bridge ping. Forms and $dotapp().load() (and Bridge) travel on the same encrypted, session-bound transport. A fo-rm does not make a click “more secure” than load(). Both ride the channel. Both require crcCheck() in PHP. How to pick the surface: Secure backend-frontend communication. Client boot and selectors: How to use $dotapp() JavaScript.

The client script is generated, not static

/assets/dotapp/dotapp.js is not a static file you vendor into app/modules/Shop/assets/. The framework generates it per client and injects per-session random key material. Those keys seal the transport for this browser session. Without that script, secure posts fail: fo-rm is never converted, CRC and CSRF fields are missing or wrong, and the PHP endpoint rejects the body.

The script route requires a usable Referer. If Referer is missing or too short, the route answers 404. Treat that as an operational fact when you test from unusual clients or strip headers. Do not load a raw copy from app/parts/js/ on production Shop pages. Always include the generated URL before Shop module scripts.

<script src="/assets/dotapp/dotapp.js"></script>
<script src="/assets/modules/Shop/js/contact.js"></script>
    

Pipeline from browser to PHP

One request, several layers. Nothing here is optional polish if you claim the Shop page is on the channel.

1. The page loads /assets/dotapp/dotapp.js (generated; Referer required or the route 404s).
2. The script holds key material for this session only.
3. The renderer has already emitted encrypted hidden fields for each fo-rm. At runtime the script converts fo-rm to a real form and hijacks submit.
4. On post, the client adds CRC and transport CSRF and sends the body as { data, crc }.
5. The request carries the header dotapp: load.
6. PHP runs $request->crcCheck(). Failure means you do not read fields.
7. On a form, $request->form(['POST'], 'saveContact', ok, err) runs only if the bound handler, URL, and method match.
8. You answer with ajaxReply. The client decodes it with parseReply.

formName binds handler, URL, and method

{{ formName(saveContact) }} must sit between <fo-rm> and </fo-rm>. The renderer emits encrypted hidden fields that bind three things under a per-form key: the PHP handler name, the action URL, and the HTTP method. Forging or swapping handlers from the HTML is not practical. A field that looks like “saveContact” in the markup is not a string you can edit into “deleteShop”.

If you omit the directive, or place it before <fo-rm> or after </fo-rm>, the renderer leaves the tag unchanged — a silent failure. The handler string in the template must equal the string you pass to form() in PHP. Tiny sketch (Shop contact). Full files: secure forms.

<fo-rm method="POST" id="contactForm" action="{{ var: $postAction }}">
  <input type="text" name="email" />
  {{ formName(saveContact) }}
  <button type="submit" id="contactBtn">Send</button>
</fo-rm>
    

Integrity: crcCheck() on the server

The client posts a payload plus a CRC. PHP crcCheck() is the public gate. If it fails, do not call form(), do not decrypt identifiers, do not write to shop_* tables. Raw fetch to the same URL will not satisfy the check. That is expected. load() adds CRC, transport CSRF, and the dotapp: load header for you — including when a hijacked fo-rm submits.

$dotapp().load("/shop/items/toggle", "POST", { id: $dotapp(el).attr("data-item") },
  function (raw) { var reply = $dotapp().parseReply(raw); },
  function (code) { /* 400 CRC, 403 CSRF, 404, 429 */ }
);
    

Encrypted identifiers are not authorization

Never put a raw primary key in the browser (value="7", data-id="7"). Encrypt with {{ enc(Shop.user.id): $id }} or Crypto::encrypt((string)$id, 'Shop.user.id'). Decrypt with the same extra key. A wrong key or a damaged token returns false — reject it.

The extra key ($key2) must be unique per identifier field. Ciphertext produced as Shop.user.id cannot be used as Shop.product.id. That stops cross-field mix-ups. It does not prove the visitor may edit that row. If one select lists many users, all under Shop.user.id, swapping one user token for another in that same field still decrypts. PHP still runs Auth::can() and an ownership query. Encryption is not authorization. Treat tokens as session-bound: do not store them in the database expecting another session to decrypt them.

A lone CSRF field is a narrow guarantee

CSRF as a web term still matters: a cross-site post should not run as the signed-in Shop operator. A lone CSRF hidden field only proves “this session could read a cookie secret”. It does not bind handler, URL, method, or fields. Next to formName plus Bridge it is a narrow guarantee — useful on the transport, not a substitute for the channel.

Named PHP functions from JS use the same channel. Binding, rate limits, and template on(click): How to call PHP from JavaScript with DotBridge.

Layers in words

Stack them. Do not pick one and skip the rest.