lhumina_code/home
23
0
Fork 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

[nu-demo] Office PDF/Doc viewing blocked — ONLYOFFICE_JWT_SECRET unset + OnlyOffice Document Server not deployed #174

New issue
Closed
opened 2026-04-24 16:04:38 +00:00 by mik-tf · 5 comments
mik-tf commented 2026-04-24 16:04:38 +00:00
Owner
Copy link

Symptom

After seeding PDFs into hero_foundry webdav root (so hero_office_server::list_documents lists them — partial fix of home#160), clicking a PDF in the Office archipelago's PDF island returns:

create_editor_session failed: RPC error -32003: ONLYOFFICE_JWT_SECRET is not set on the server

Same for .docx, .xlsx, .pptx.

Root cause

hero_office_server/src/lib.rs uses OnlyOffice Document Server as the rendering engine:

if state.config.oo_jwt_secret.is_empty() {
    return Err((-32003, "ONLYOFFICE_JWT_SECRET is not set on the server".into()));
}

Two independent gaps:

1. The JWT secret env var is unset

hero_office_server reads ONLYOFFICE_JWT_SECRET from env. Not set by service_install_all nor pre-populated in the hero_proc action env. Dummy value would unblock the error but doesn't solve (2).

2. OnlyOffice Document Server is not running

hero_office generates an editor_url pointing at an OnlyOffice instance that is supposed to render the doc in an iframe. On herodemo there is no such instance:

  • No onlyoffice/documentserver Docker container
  • No bare-VM OnlyOffice install
  • No integration listed in hero_skills installers or service_office.nu

The entire Office viewing flow depends on an external Document Server that the nu-shell stack doesn't ship.

Options

A. Ship OnlyOffice Document Server on the VM

The canonical path. OnlyOffice is distributed as a Docker container (~3 GB image, needs ~6 GB RAM at runtime, plus PostgreSQL + Redis). Would need:

  • docker + docker-compose on the VM (or podman)
  • Pin a version of onlyoffice/documentserver
  • Configure ONLYOFFICE_JWT_SECRET on both sides (hero_office + OnlyOffice container)
  • Expose the OnlyOffice port via hero_router (e.g. /onlyoffice/...)
  • Handle CORS + JWT signing

Not trivial. Adds another moving part. Right answer for prod.

B. Swap in a simpler PDF viewer for the demo

hero_books already has a PDF viewer (/book/<name>/pdf/viewer) that uses HTML5 PDF.js — no OnlyOffice needed. Demo could:

  • Keep PDFs in webdav root (as now)
  • Route PDF click through a PDF.js viewer iframe instead of OnlyOffice
  • Restrict .docx/.xlsx/.pptx viewing to 'download' mode

This is what hero.gent04.grid.tf shows — PDFs render in-browser via PDF.js, not OnlyOffice. Check how the hero_zero Docker build wired it.

C. Allow downloading only, no in-browser viewer

Simplest. Click PDF → browser downloads it → user opens locally. Document the limitation. Defers (A) until Docker support is worth adding.

Demo workaround (herodemo 2026-04-24)

None — PDFs listed but not viewable. Filing this + leaving demo in 'PDFs visible but not clickable to view' state. User can see them in the Files island (via webdav directly), where the browser-native PDF viewer handles them.

Related

  • home#160 — consolidated demo state (§Office PDF island was listed as a gap)
  • hero_zero has OnlyOffice integration — consult its docker-compose / entrypoint.sh for the pattern to port into nu-shell.

Signed-off-by: mik-tf

## Symptom After seeding PDFs into hero_foundry webdav root (so `hero_office_server::list_documents` lists them — partial fix of [home#160](https://forge.ourworld.tf/lhumina_code/home/issues/160)), clicking a PDF in the Office archipelago's PDF island returns: ``` create_editor_session failed: RPC error -32003: ONLYOFFICE_JWT_SECRET is not set on the server ``` Same for .docx, .xlsx, .pptx. ## Root cause `hero_office_server/src/lib.rs` uses **OnlyOffice Document Server** as the rendering engine: ```rust if state.config.oo_jwt_secret.is_empty() { return Err((-32003, "ONLYOFFICE_JWT_SECRET is not set on the server".into())); } ``` Two independent gaps: ### 1. The JWT secret env var is unset `hero_office_server` reads `ONLYOFFICE_JWT_SECRET` from env. Not set by `service_install_all` nor pre-populated in the hero_proc action env. Dummy value would unblock the error but doesn't solve (2). ### 2. OnlyOffice Document Server is not running hero_office generates an `editor_url` pointing at an OnlyOffice instance that is supposed to render the doc in an iframe. On herodemo there is no such instance: - No `onlyoffice/documentserver` Docker container - No bare-VM OnlyOffice install - No integration listed in hero_skills installers or service_office.nu The entire Office viewing flow depends on an external Document Server that the nu-shell stack doesn't ship. ## Options ### A. Ship OnlyOffice Document Server on the VM The canonical path. OnlyOffice is distributed as a Docker container (~3 GB image, needs ~6 GB RAM at runtime, plus PostgreSQL + Redis). Would need: - `docker` + `docker-compose` on the VM (or podman) - Pin a version of `onlyoffice/documentserver` - Configure `ONLYOFFICE_JWT_SECRET` on both sides (hero_office + OnlyOffice container) - Expose the OnlyOffice port via hero_router (e.g. `/onlyoffice/...`) - Handle CORS + JWT signing Not trivial. Adds another moving part. Right answer for prod. ### B. Swap in a simpler PDF viewer for the demo hero_books already has a PDF viewer (`/book/<name>/pdf/viewer`) that uses HTML5 PDF.js — no OnlyOffice needed. Demo could: - Keep PDFs in webdav root (as now) - Route PDF click through a PDF.js viewer iframe instead of OnlyOffice - Restrict .docx/.xlsx/.pptx viewing to 'download' mode This is what hero.gent04.grid.tf shows — PDFs render in-browser via PDF.js, not OnlyOffice. Check how the hero_zero Docker build wired it. ### C. Allow downloading only, no in-browser viewer Simplest. Click PDF → browser downloads it → user opens locally. Document the limitation. Defers (A) until Docker support is worth adding. ## Demo workaround (herodemo 2026-04-24) None — PDFs listed but not viewable. Filing this + leaving demo in 'PDFs visible but not clickable to view' state. User can see them in the Files island (via webdav directly), where the browser-native PDF viewer handles them. ## Related - [home#160](https://forge.ourworld.tf/lhumina_code/home/issues/160) — consolidated demo state (§Office PDF island was listed as a gap) - hero_zero has OnlyOffice integration — consult its docker-compose / entrypoint.sh for the pattern to port into nu-shell. Signed-off-by: mik-tf
mik-tf commented 2026-04-24 22:01:05 +00:00
Author
Owner
Copy link

Demo hotfix applied 2026-04-24

hero_office_ui::editor_page patched with a browser-native PDF short-circuit:

  1. Direct PDFs: clicking a .pdf returns an HTML page with <embed type="application/pdf"> pointing at /files/{ctx}/{name}?inline=1. proxy_file gained an inline=1 query that switches Content-Disposition from attachment to inline. Browser native viewer renders.
  2. Companion-PDF mode for .docx/.xlsx/.pptx: list_documents is queried for a sibling .pdf with the same stem. If found, the iframe renders that PDF with a small badge "PDF preview of ". Otherwise falls through to OnlyOffice (still broken).
  3. Seed content: 5 .pptx (Presentations), 5 .xlsx (Spreadsheets), companion PDFs generated via Chrome headless (google-chrome-stable --headless --print-to-pdf). Distributed to geomind, incubaid, threefold, default, root contexts.

Verified: Presentations / Spreadsheets / Documents / PDF islands now show files; clicking renders inline.

Prod-level fix needed

The companion-PDF trick works for read-only demo viewing but not for editing.

  1. Ship OnlyOffice Document Server — package as a docker container in hero_skills installer, default to a JWT signed with HERO_SECRET, expose via hero_router at /onlyoffice/.... Adds 3 GB image + ~6 GB runtime RAM. The proper path for full Office editing.
  2. Auto-generate companion PDFs on upload — when a .docx/.xlsx/.pptx is uploaded via foundry webdav, run libreoffice --headless --convert-to pdf (or pandoc for simple md-derived docs) to produce a synced .pdf for browser-native preview. Cache invalidated on file modification.
  3. Document the demo-time PDF embed trick in hero_office's README so other demos can apply it without OnlyOffice.
  4. Per-format viewer fallback policy — make the short-circuit configurable via env (HERO_OFFICE_PDF_EMBED_ONLY=1) for deployments that explicitly don't run OnlyOffice.
## Demo hotfix applied 2026-04-24 `hero_office_ui::editor_page` patched with a browser-native PDF short-circuit: 1. **Direct PDFs**: clicking a `.pdf` returns an HTML page with `<embed type="application/pdf">` pointing at `/files/{ctx}/{name}?inline=1`. proxy_file gained an `inline=1` query that switches `Content-Disposition` from `attachment` to `inline`. Browser native viewer renders. 2. **Companion-PDF mode** for `.docx`/`.xlsx`/`.pptx`: list_documents is queried for a sibling `.pdf` with the same stem. If found, the iframe renders that PDF with a small badge "PDF preview of <filename>". Otherwise falls through to OnlyOffice (still broken). 3. **Seed content**: 5 .pptx (Presentations), 5 .xlsx (Spreadsheets), companion PDFs generated via Chrome headless (`google-chrome-stable --headless --print-to-pdf`). Distributed to geomind, incubaid, threefold, default, root contexts. **Verified:** Presentations / Spreadsheets / Documents / PDF islands now show files; clicking renders inline. ## Prod-level fix needed The companion-PDF trick works for read-only demo viewing but not for editing. 1. **Ship OnlyOffice Document Server** — package as a docker container in hero_skills installer, default to a JWT signed with HERO_SECRET, expose via hero_router at `/onlyoffice/...`. Adds 3 GB image + ~6 GB runtime RAM. The proper path for full Office editing. 2. **Auto-generate companion PDFs on upload** — when a .docx/.xlsx/.pptx is uploaded via foundry webdav, run `libreoffice --headless --convert-to pdf` (or `pandoc` for simple md-derived docs) to produce a synced `.pdf` for browser-native preview. Cache invalidated on file modification. 3. **Document the demo-time PDF embed trick** in hero_office's README so other demos can apply it without OnlyOffice. 4. **Per-format viewer fallback policy** — make the short-circuit configurable via env (`HERO_OFFICE_PDF_EMBED_ONLY=1`) for deployments that explicitly don't run OnlyOffice.
mik-tf commented 2026-04-25 00:33:03 +00:00
Author
Owner
Copy link

OnlyOffice deployed live on herodemo (2026-04-24)

What landed

  1. OnlyOffice Document Server running as Docker container on the VM:

    • Image onlyoffice/documentserver:latest (3.9 GB), pulled to /data/docker (btrfs storage driver — see home#181)
    • Container exposes 127.0.0.1:8088
    • JWT enabled, secret matches hero_office_server's action env (hero-demo-jwt-secret-change-in-prod)

  2. Reverse proxy in hero_office_ui so OnlyOffice fits hero_router's per-service URL space:

    • PR opened: lhumina_code/hero_office#3 (development_mik_proxy_onlyoffice → development)
    • New handlers proxy_onlyoffice_root / proxy_onlyoffice_path (any HTTP method) at /onlyoffice and /onlyoffice/*rest
    • Mirrors existing proxy_file pattern; OnlyOffice traffic stays on the single TF Grid name proxy
    • Bonus: editor_page PDF short-circuit (browser native) + proxy_file?inline=1 for read-only PDF viewing

  3. Action env wiring on herodemo:

    • hero_office_ui: OO_SERVER_URL=https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice, OO_UPSTREAM_BASE=http://127.0.0.1:8088
    • hero_office_server: ONLYOFFICE_JWT_SECRET=..., CONNECTOR_EXTERNAL_URL=https://herodemo.gent01.grid.tf

Verified end-to-end

curl /hero_office/ui/onlyoffice/healthcheck   → "true"
curl /hero_office/ui/word/edit/coop.docx?context=geomind
  → returns OnlyOffice editor wrapper page with:
     <script src="https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice/web-apps/apps/api/documents/api.js">
     "url":      "https://herodemo.gent01.grid.tf/hero_office/ui/files/geomind/coop.docx"
     "callbackUrl":"https://herodemo.gent01.grid.tf/hero_office/ui/callback/geomind"
     (proper JWT signed)

Clicking any .docx / .xlsx / .pptx in the Office archipelago now loads the real OnlyOffice editor in the iframe with edit-mode + autosave callback. .pdf continues to render via browser-native viewer (faster, no editor JS overhead).

Why this approach (vs router-side TCP route)

hero_router proxies to per-service Unix sockets only (hero_router/src/server/routes.rs:1941-1948). Adding TCP-target routing is a cross-cutting change with broader review surface. Since hero_office_ui already has an HTTP-proxy handler (proxy_file for foundry webdav), bridging OnlyOffice inside the same service via a sibling handler is the smaller, more focused change — and keeps OnlyOffice traffic semantically inside the office archipelago. PR #3 lays this out.

Demo state

  • Office archipelago fully working for editing (.docx/.xlsx/.pptx → real OnlyOffice editor)
  • PDF viewing → browser native (fast)
  • All Office sub-types (Documents/Spreadsheets/Presentations/PDF/Diagrams) backed by content
  • Companion-PDF libreoffice fallback from earlier work is no longer needed at runtime, but the libreoffice --headless --convert-to pdf workflow remains tracked in home#178 as a lightweight viewer fallback for deploys that don't run OnlyOffice.

Closing this issue once PR #3 lands. Demo VM is unblocked now.

Signed-off-by: mik-tf

## OnlyOffice deployed live on herodemo (2026-04-24) ### What landed 1. **OnlyOffice Document Server** running as Docker container on the VM: - Image `onlyoffice/documentserver:latest` (3.9 GB), pulled to `/data/docker` (btrfs storage driver — see home#181) - Container exposes `127.0.0.1:8088` - JWT enabled, secret matches `hero_office_server`'s action env (`hero-demo-jwt-secret-change-in-prod`) 2. **Reverse proxy** in `hero_office_ui` so OnlyOffice fits hero_router's per-service URL space: - PR opened: https://forge.ourworld.tf/lhumina_code/hero_office/pulls/3 (`development_mik_proxy_onlyoffice` → `development`) - New handlers `proxy_onlyoffice_root` / `proxy_onlyoffice_path` (any HTTP method) at `/onlyoffice` and `/onlyoffice/*rest` - Mirrors existing `proxy_file` pattern; OnlyOffice traffic stays on the single TF Grid name proxy - Bonus: `editor_page` PDF short-circuit (browser native) + `proxy_file?inline=1` for read-only PDF viewing 3. **Action env wiring** on herodemo: - `hero_office_ui`: `OO_SERVER_URL=https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice`, `OO_UPSTREAM_BASE=http://127.0.0.1:8088` - `hero_office_server`: `ONLYOFFICE_JWT_SECRET=...`, `CONNECTOR_EXTERNAL_URL=https://herodemo.gent01.grid.tf` ### Verified end-to-end ``` curl /hero_office/ui/onlyoffice/healthcheck → "true" curl /hero_office/ui/word/edit/coop.docx?context=geomind → returns OnlyOffice editor wrapper page with: <script src="https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice/web-apps/apps/api/documents/api.js"> "url": "https://herodemo.gent01.grid.tf/hero_office/ui/files/geomind/coop.docx" "callbackUrl":"https://herodemo.gent01.grid.tf/hero_office/ui/callback/geomind" (proper JWT signed) ``` Clicking any `.docx` / `.xlsx` / `.pptx` in the Office archipelago now loads the **real OnlyOffice editor** in the iframe with edit-mode + autosave callback. `.pdf` continues to render via browser-native viewer (faster, no editor JS overhead). ### Why this approach (vs router-side TCP route) hero_router proxies to per-service Unix sockets only (`hero_router/src/server/routes.rs:1941-1948`). Adding TCP-target routing is a cross-cutting change with broader review surface. Since `hero_office_ui` already has an HTTP-proxy handler (`proxy_file` for foundry webdav), bridging OnlyOffice inside the same service via a sibling handler is the smaller, more focused change — and keeps OnlyOffice traffic semantically inside the office archipelago. PR #3 lays this out. ### Demo state - Office archipelago fully working for editing (.docx/.xlsx/.pptx → real OnlyOffice editor) - PDF viewing → browser native (fast) - All Office sub-types (Documents/Spreadsheets/Presentations/PDF/Diagrams) backed by content - Companion-PDF libreoffice fallback from earlier work is no longer needed at runtime, but the `libreoffice --headless --convert-to pdf` workflow remains tracked in [home#178](https://forge.ourworld.tf/lhumina_code/home/issues/178) as a lightweight viewer fallback for deploys that don't run OnlyOffice. Closing this issue once PR #3 lands. Demo VM is unblocked now. Signed-off-by: mik-tf
mik-tf commented 2026-04-25 02:45:02 +00:00
Author
Owner
Copy link

✅ Office editing fully working on herodemo (2026-04-25)

End-to-end editor works for .docx / .xlsx / .pptx — real OnlyOffice with slide rendering, formulas, comments, autosave.

What it took (full chain)

Infrastructure on herodemo:

  • Docker installed + reconfigured for /data/docker with btrfs storage driver (overlay2 fails on TF Grid flist whiteout files)
  • OnlyOffice Document Server container (onlyoffice/documentserver:latest, 3.9 GB, JWT enabled, secret matching hero_office_server's action env)
  • nginx in front of hero_router for basic auth gating + WS support (admin:admin123, see home#182)

Code in hero_office_ui (PR #3):

  • proxy_onlyoffice_root / proxy_onlyoffice_path — HTTP reverse proxy to OnlyOffice container at /hero_office/ui/onlyoffice/*
  • WebSocket pass-through via axum::WebSocketUpgrade + tokio_tungstenite::connect_async (socket.io requires WS for editor state)
  • Streaming response body (long-polling fallback can't be buffered)
  • X-Forwarded-Host: <host>/hero_office/ui/onlyoffice so OO builds correct public URLs
  • X-Forwarded-Proto: https for the cache URL protocol
  • Content-Security-Policy: upgrade-insecure-requests on the editor page (silently upgrades any residual http:// URLs OO emits)
  • PDF short-circuit (browser native viewer, faster than launching the editor)

Code in hero_office_server (PR #3):

  • JWT permissions widened: edit, download, print, copy, comment, review, fillForms, modifyFilter, modifyContentControl, chat, protect

Action env on herodemo:

  • hero_office_ui: OO_SERVER_URL=https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice, OO_UPSTREAM_BASE=http://10.1.2.2:8088
  • hero_office_server: ONLYOFFICE_JWT_SECRET=..., CONNECTOR_EXTERNAL_URL=http://10.1.2.2:9990 (internal hero_router URL — OO container fetches files without going back through public auth gate)

Architecture — single-domain TLS gateway with auth

browser
  │
  ▼ HTTPS + Basic Auth
TF Grid name proxy (herodemo.gent01.grid.tf)
  │
  ▼ HTTP
nginx (10.1.2.2:9988, htpasswd auth, WS upgrade headers)
  │
  ▼ HTTP (no auth)
hero_router (10.1.2.2:9990)
  │
  ▼ Unix socket
hero_office_ui (proxy_onlyoffice_*)
  │
  ▼ HTTP / WS
OnlyOffice Document Server (10.1.2.2:8088, Docker)
  │
  ▼ HTTP (back to hero_router internal — bypass nginx auth)
hero_office_ui (proxy_file → fetches file from foundry webdav)

The "back to hero_router internal" loop matters: OO container needs to fetch documents from hero_office_ui but must NOT go through public-gateway HTTPS+auth (no credentials in container). Splitting OO_SERVER_URL (browser-side, public HTTPS) from CONNECTOR_EXTERNAL_URL (OO-container-side, internal HTTP) solves this cleanly.

PR #3 status

hero_office/development_mik_proxy_onlyoffice → lhumina_code/hero_office#3

Three commits:

  • f1abfb5 — initial PDF native + HTTP-only OnlyOffice proxy
  • dc9c813 — WebSocket pass-through + streaming response body
  • 86a834c — X-Forwarded-Host/Proto + CSP upgrade-insecure-requests + JWT permissions widened

Closing this issue once PR #3 lands.

Related

  • home#178 — at-click-time libreoffice fallback (companion path; orthogonal to this OnlyOffice install)
  • home#181 — Docker on TF Grid (btrfs storage driver)
  • home#182 — auth gating (nginx basic auth on demo, hero_proxy oauth/bearer/optional canonical)

Signed-off-by: mik-tf

## ✅ Office editing fully working on herodemo (2026-04-25) End-to-end editor works for `.docx` / `.xlsx` / `.pptx` — real OnlyOffice with slide rendering, formulas, comments, autosave. ### What it took (full chain) **Infrastructure on herodemo:** - Docker installed + reconfigured for `/data/docker` with `btrfs` storage driver (overlay2 fails on TF Grid flist whiteout files) - OnlyOffice Document Server container (`onlyoffice/documentserver:latest`, 3.9 GB, JWT enabled, secret matching `hero_office_server`'s action env) - nginx in front of hero_router for basic auth gating + WS support (admin:admin123, see home#182) **Code in `hero_office_ui` (PR #3):** - `proxy_onlyoffice_root` / `proxy_onlyoffice_path` — HTTP reverse proxy to OnlyOffice container at `/hero_office/ui/onlyoffice/*` - WebSocket pass-through via `axum::WebSocketUpgrade` + `tokio_tungstenite::connect_async` (socket.io requires WS for editor state) - Streaming response body (long-polling fallback can't be buffered) - `X-Forwarded-Host: <host>/hero_office/ui/onlyoffice` so OO builds correct public URLs - `X-Forwarded-Proto: https` for the cache URL protocol - `Content-Security-Policy: upgrade-insecure-requests` on the editor page (silently upgrades any residual `http://` URLs OO emits) - PDF short-circuit (browser native viewer, faster than launching the editor) **Code in `hero_office_server` (PR #3):** - JWT permissions widened: `edit, download, print, copy, comment, review, fillForms, modifyFilter, modifyContentControl, chat, protect` **Action env on herodemo:** - `hero_office_ui`: `OO_SERVER_URL=https://herodemo.gent01.grid.tf/hero_office/ui/onlyoffice`, `OO_UPSTREAM_BASE=http://10.1.2.2:8088` - `hero_office_server`: `ONLYOFFICE_JWT_SECRET=...`, `CONNECTOR_EXTERNAL_URL=http://10.1.2.2:9990` (internal hero_router URL — OO container fetches files without going back through public auth gate) ### Architecture — single-domain TLS gateway with auth ``` browser │ ▼ HTTPS + Basic Auth TF Grid name proxy (herodemo.gent01.grid.tf) │ ▼ HTTP nginx (10.1.2.2:9988, htpasswd auth, WS upgrade headers) │ ▼ HTTP (no auth) hero_router (10.1.2.2:9990) │ ▼ Unix socket hero_office_ui (proxy_onlyoffice_*) │ ▼ HTTP / WS OnlyOffice Document Server (10.1.2.2:8088, Docker) │ ▼ HTTP (back to hero_router internal — bypass nginx auth) hero_office_ui (proxy_file → fetches file from foundry webdav) ``` The "back to hero_router internal" loop matters: OO container needs to fetch documents from `hero_office_ui` but must NOT go through public-gateway HTTPS+auth (no credentials in container). Splitting `OO_SERVER_URL` (browser-side, public HTTPS) from `CONNECTOR_EXTERNAL_URL` (OO-container-side, internal HTTP) solves this cleanly. ### PR #3 status `hero_office/development_mik_proxy_onlyoffice` → https://forge.ourworld.tf/lhumina_code/hero_office/pulls/3 Three commits: - `f1abfb5` — initial PDF native + HTTP-only OnlyOffice proxy - `dc9c813` — WebSocket pass-through + streaming response body - `86a834c` — X-Forwarded-Host/Proto + CSP upgrade-insecure-requests + JWT permissions widened Closing this issue once PR #3 lands. ### Related - [home#178](https://forge.ourworld.tf/lhumina_code/home/issues/178) — at-click-time libreoffice fallback (companion path; orthogonal to this OnlyOffice install) - [home#181](https://forge.ourworld.tf/lhumina_code/home/issues/181) — Docker on TF Grid (btrfs storage driver) - [home#182](https://forge.ourworld.tf/lhumina_code/home/issues/182) — auth gating (nginx basic auth on demo, hero_proxy oauth/bearer/optional canonical) Signed-off-by: mik-tf
mik-tf commented 2026-04-25 15:17:14 +00:00
Author
Owner
Copy link

Merged to hero_office/development 2026-04-25

Squash commit 2dbc543 on hero_office development:

feat(office): OnlyOffice integration via hero_office_ui reverse proxy (#174)

PR #3 closed. The OnlyOffice connector is now upstream — fresh deploys using development everywhere will have the integration code without needing the demo-VM hotfix branch.

Still demo-VM-only (Phase 2 work):

  • Docker btrfs setup → hero_skills/development_mik_docker_btrfs
  • OnlyOffice container deploy → hero_skills/development_mik_onlyoffice_install (service_onlyoffice.nu)
  • Action env wiring (CONNECTOR_EXTERNAL_URL, OO_SERVER_URL, OO_UPSTREAM_BASE) → hero_skills/development_mik_office_env

Signed-off-by: mik-tf

## Merged to hero_office/development 2026-04-25 Squash commit `2dbc543` on hero_office development: > feat(office): OnlyOffice integration via hero_office_ui reverse proxy (#174) PR #3 closed. The OnlyOffice connector is now upstream — fresh deploys using `development` everywhere will have the integration code without needing the demo-VM hotfix branch. Still demo-VM-only (Phase 2 work): - Docker btrfs setup → `hero_skills/development_mik_docker_btrfs` - OnlyOffice container deploy → `hero_skills/development_mik_onlyoffice_install` (`service_onlyoffice.nu`) - Action env wiring (CONNECTOR_EXTERNAL_URL, OO_SERVER_URL, OO_UPSTREAM_BASE) → `hero_skills/development_mik_office_env` Signed-off-by: mik-tf
mik-tf commented 2026-04-25 16:22:21 +00:00
Author
Owner
Copy link

Deploy-side resolved: new service_onlyoffice module manages the OnlyOffice Document Server Docker container (pull/run/JWT/healthcheck), and OO_UPSTREAM_BASE is forwarded to hero_office_ui action. PR lhumina_code/hero_office#3 (commit 2dbc543) wires the proxy on the code side. Closing if no remaining gap — please reopen if there is one.

Part of: lhumina_code/hero_skills@7c823d1 (PR lhumina_code/hero_skills#126).
Tracker: #185.

Deploy-side resolved: new `service_onlyoffice` module manages the OnlyOffice Document Server Docker container (pull/run/JWT/healthcheck), and `OO_UPSTREAM_BASE` is forwarded to `hero_office_ui` action. PR https://forge.ourworld.tf/lhumina_code/hero_office/pulls/3 (commit `2dbc543`) wires the proxy on the code side. Closing if no remaining gap — please reopen if there is one. Part of: https://forge.ourworld.tf/lhumina_code/hero_skills/commit/7c823d1 (PR https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/126). Tracker: https://forge.ourworld.tf/lhumina_code/home/issues/185.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#174
No description provided.