# Concresca full-root release r5 — diagnostic CSRF repair

Release: `concresca-full-root-20260927-r5`  
Diagnostic build: `concresca-locked-diagnostics-20260927-root-r5`

## Deploy the complete release, then reopen diagnostics

This is the entire consolidated website/application, based on the r4 full-root release. No partial overlay or earlier repair package is required. Extract into the existing actual website document root. There is no outer project folder and no `public/` tree to merge.

Do not empty that directory. Preserve the existing root `.htaccess`, database, external private environment, hosting Python environment, mutable `runtime/` state, and the private `.concresca-diagnostics/` directory in the account home. This archive deliberately does not contain or replace those host-specific resources. Use your existing backup/deployment process for the upload.

For this PHP diagnostic fix, no Python activation command is needed. After extraction, open a **fresh GET** of:

```text
https://concresca.com/concresca-diagnostics.php
```

Do not use Back/Resubmit to reuse an old POST. The footer should identify `concresca-locked-diagnostics-20260927-root-r5`. The public, non-secret execution check is:

```text
https://concresca.com/concresca-diagnostics.php?action=ping
```

Read the current code from `account-home/.concresca-diagnostics/access-code.txt`, outside the website. Enter it only into the diagnostic page. An existing unexpired code is retained; normal 24-hour expiration still applies. After unlocking, run diagnostics and download the redacted report. Never share the code, cookie, environment file or raw logs.

If access is rejected again, the page now provides a **Download access-error report** button. This separate report contains only enumerated reasons and boolean presence checks, not the submitted code, tokens, cookies, full host paths, IP addresses or raw request headers. Authenticated AJAX failures also preserve a sanitized access-error result in the downloaded diagnostic report.

## What was repaired

The r4 diagnostic page emitted `Referrer-Policy: no-referrer`. Browsers can therefore send `Origin: null` on an ordinary HTML form POST. The same page explicitly rejected that origin before examining the access code. A native Apache/PHP HTTPS reproduction of the unmodified r4 file returned HTTP 403 with `CSRF_REJECTED` despite the correct locally generated access code, matching session cookie, and matching form token. The reproduction client supplied the documented browser header; it was not an automated browser-navigation test.

R5 emits `Referrer-Policy: same-origin` and an equivalent page-level meta policy. Same-origin forms no longer need to be made compatible by weakening origin checks, while cross-origin referrers remain suppressed. `Origin: null`, foreign origins, cross-origin fetch metadata and invalid tokens are still rejected. The synchronized session token, HTTPS, secure/HttpOnly/SameSite=Strict cookie, login rate limit, session expiration and code rotation remain enforced.

The cookie explicitly clears its Domain parameter. Without that explicit setting, an inherited PHP cookie domain can invalidate the browser's `__Host-` cookie requirements. A native test uses an inherited `.concresca.com` setting and verifies the emitted cookie has no Domain attribute and supports the complete unlock/read/lock flow. This tests a possible configuration hazard, not evidence of your host's actual PHP settings.

## Scope and the original readiness failure

This release fixes a demonstrated defect in the **diagnostic access path**. It does not establish that the live Python dispatcher is active or that autonomous verification is passing. The Python application/verification logic from r4 is retained unchanged. No readiness gate is bypassed and no passing receipt is shipped.

The existing full host activation entry point remains included for your deployment workflow:

```sh
python3 concresca-repair/activate.py
```

Run it only on the hosting server, with the application's existing Python environment. It verifies the full-file manifest, preserves unrelated host configuration, tests live runtime routing, and installs the automatic verifier schedule. It is **not required to open the PHP diagnostics**, and should not be used as a prerequisite to obtaining the report about a failed Python deployment. `--check-only` verifies distributed file integrity without host activation or a readiness claim.

## Test evidence

See `concresca-repair/TEST-RESULTS.md`, `VALIDATION.json`, and `CSRF-REPRODUCTION.json`. The local regression run includes 259 Python tests (19 are real loopback Apache/PHP HTTPS roundtrips), 46 PHP function assertions, and 86 synthetic JavaScript assertions. Real browser navigation and production Passenger/LiteSpeed/MySQL operation are not established by these results. The final archive is separately extracted and revalidated before delivery.

## References

Browser referrer behavior: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy  
Cookie-prefix requirements: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie  
PHP cookie options: https://www.php.net/manual/en/function.session-set-cookie-params.php  
CSRF defenses: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html