2.0 KiB
2.0 KiB
Media Publisher Extension Runtime V1
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.