root/geo

Files

T

root 5ff2e2e74c refactor(tenant): drop legacy plugin_installations, migrate monitoring to desktop_clients

Hard cutover from the browser-extension plugin flow to desktop clients:
remove plugin_installations/plugin_sessions tables and related service,
handler, router, and generated model code; migrate monitoring quotas
and collector types to desktop_clients (UUID primary_client_id);
recreate platform_access_snapshots keyed by client_id; update dev-seed
and callback types accordingly; mark legacy design docs as historical.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-20 13:52:35 +08:00

2.3 KiB

Raw Blame History

Media Publisher Extension Runtime V1（旧版设计）

旧版设计说明：本文描述的是基于浏览器插件、plugin_installations、plugin_sessions 的旧执行方案。自 2026-04-20 起，当前实现已切换到 desktop_clients / desktop client 架构。本文保留用于工作记录与方案追溯，不再作为当前实现依据。

Goal

Browser extension actions must keep working for two different modes:

Foreground actions triggered from the SaaS UI, such as bind and publish.
Future background actions that continue after the SaaS page is closed, such as checking Doubao/Kimi inclusion status.

Identity Model

Do not reuse the SaaS web JWT inside the extension background runtime.

Use two layers instead:

SaaS user session
- Used only when the user is actively logged into the admin web app.
- Registers or refreshes a plugin installation record.
Plugin installation identity
- One record per browser installation.
- Stored in plugin_installations.
- Holds a long-lived installation token hash in the backend.
- Lets future background jobs authenticate as a device/runtime, not as a browser tab.

Current Tables

plugin_installations
- Stable browser installation identity.
plugin_sessions
- Short-lived action session for bind, check, publish.
publish_batches
- One multi-platform publish request.
publish_records
- One platform result row per publish.

Current Flow

Admin page pings the extension.
Extension returns a stable installation_key.
Admin page calls POST /api/tenant/media/plugin-installations/register.
Backend returns plugin_installation_id + installation_token.
Admin page passes them back to the extension.
Extension stores that installation identity locally.
Bind or publish requests create short-lived plugin_sessions.
Callbacks write bind/publish results using session token validation.

Future Background Tasks

Background jobs should be scheduled from the extension service worker using the stored installation identity.

Typical examples:

Poll whether generated articles are included by Doubao/Kimi.
Retry resolving a published article URL when only a platform draft ID is known.
Re-check local platform login health.

Those future endpoints should authenticate with the installation token, not the SaaS web JWT.

2.3 KiB Raw Blame History