Epic: make Quasar first-class on the web and Electron with StarIntel OIDC #56

New issue

Open

opened 2026-08-26 07:36:22 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-26 07:36:22 +00:00

(Migrated from github.com)

Goal

Keep one Quasar application codebase that runs as both:

the public browser application at https://quasar.starintel.actor
an Electron desktop package

Electron must remain a packaging/runtime adapter, not the product architecture.

Authentication

Add Sign in with StarIntel using the central StarIntel OIDC provider.

Browser flow:

Authorization Code + PKCE
redirect through auth.starintel.actor
secure browser session/token handling

Electron flow:

use the system browser for OIDC
return through a deep link/loopback callback
do not collect StarIntel passwords inside Electron

Shared app requirements

shared routes/components/state model
shared API client layer
explicit platform adapters for browser vs Electron-only abilities
browser build remains fully usable without Electron
local-only capabilities are exposed only by the Electron/local host adapter
server authorization must never rely on hiding UI controls

Relationship to existing control-plane work

Build on the current Common Lisp control plane and principal/capability authorization work rather than creating a second application authority.

Relevant existing issues include #2 and #50.

Acceptance

npm/frontend web build produces a deployable Quasar web app
a user can sign in with one StarIntel account in the browser
the same identity can sign into Electron through the system browser
browser sessions cannot invoke local-only actor/filesystem capabilities
Electron can expose local abilities through an explicit host boundary
browser and Electron pass shared UI/control-plane tests

Non-goals

no permanent fork solely for Electron packaging
no separate desktop user/account database
no arbitrary credential storage in renderer code

## Goal Keep one Quasar application codebase that runs as both: - the public browser application at `https://quasar.starintel.actor` - an Electron desktop package Electron must remain a packaging/runtime adapter, not the product architecture. ## Authentication Add **Sign in with StarIntel** using the central StarIntel OIDC provider. Browser flow: - Authorization Code + PKCE - redirect through `auth.starintel.actor` - secure browser session/token handling Electron flow: - use the system browser for OIDC - return through a deep link/loopback callback - do not collect StarIntel passwords inside Electron ## Shared app requirements - shared routes/components/state model - shared API client layer - explicit platform adapters for browser vs Electron-only abilities - browser build remains fully usable without Electron - local-only capabilities are exposed only by the Electron/local host adapter - server authorization must never rely on hiding UI controls ## Relationship to existing control-plane work Build on the current Common Lisp control plane and principal/capability authorization work rather than creating a second application authority. Relevant existing issues include #2 and #50. ## Acceptance - `npm`/frontend web build produces a deployable Quasar web app - a user can sign in with one StarIntel account in the browser - the same identity can sign into Electron through the system browser - browser sessions cannot invoke local-only actor/filesystem capabilities - Electron can expose local abilities through an explicit host boundary - browser and Electron pass shared UI/control-plane tests ## Non-goals - no permanent fork solely for Electron packaging - no separate desktop user/account database - no arbitrary credential storage in renderer code