openxiangda 1.0.83 → 1.0.85

package/lib/http.js

@@ -1,11 +1,16 @@
 const { maskText } = require('./utils');
 
+const DEFAULT_REQUEST_TIMEOUT_MS = 60000;
+
 async function requestJson(baseUrl, apiPath, options = {}) {
   if (typeof fetch !== 'function') {
     throw new Error('当前 Node.js 版本不支持 fetch，请使用 Node.js 18 或更高版本');
   }
 
   const url = `${baseUrl.replace(/\/+$/, '')}${apiPath}`;
+  const timeoutMs = normalizeTimeoutMs(options.timeoutMs, DEFAULT_REQUEST_TIMEOUT_MS);
+  const controller = new AbortController();
+  const timer = setTimeout(() => controller.abort(), timeoutMs);
   const headers = {
     accept: 'application/json',
     ...(options.headers || {}),
@@ -17,12 +22,23 @@ async function requestJson(baseUrl, apiPath, options = {}) {
     headers.authorization = `Bearer ${options.accessToken}`;
   }
 
-  const response = await fetch(url, {
-    method: options.method || 'GET',
-    headers,
-    body:
-      options.body === undefined ? undefined : JSON.stringify(options.body),
-  });
+  let response;
+  try {
+    response = await fetch(url, {
+      method: options.method || 'GET',
+      headers,
+      body:
+        options.body === undefined ? undefined : JSON.stringify(options.body),
+      signal: controller.signal,
+    });
+  } catch (error) {
+    if (isAbortError(error)) {
+      throw new Error(maskText(`HTTP request timed out after ${timeoutMs}ms: ${apiPath}`));
+    }
+    throw error;
+  } finally {
+    clearTimeout(timer);
+  }
 
   const text = await response.text();
   let payload = null;
@@ -42,6 +58,19 @@ async function requestJson(baseUrl, apiPath, options = {}) {
   return payload;
 }
 
+function normalizeTimeoutMs(value, fallback) {
+  const parsed = Number(value);
+  if (Number.isFinite(parsed) && parsed > 0) return parsed;
+  return fallback;
+}
+
+function isAbortError(error) {
+  return (
+    error?.name === 'AbortError' ||
+    String(error?.message || '').toLowerCase().includes('aborted')
+  );
+}
+
 module.exports = {
   requestJson,
 };

package/openxiangda-skills/SKILL.md

@@ -28,6 +28,7 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 | 审批流程 / workflow / 流程节点 / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow validate / create / publish` |
 | 自动化 / 定时任务 / 提交触发 / cron | `openxiangda-workflow-automation` | `openxiangda automation validate / create / publish / enable` |
 | App Function / function_call / 可复用后端逻辑 | `openxiangda-workflow-automation` | declare `src/resources/functions/<code>.json` + `src/functions/<code>/index.ts` |
+| 应用登录 / Auth SDK / 手机号验证码 / CAS / 钉钉免登 | `openxiangda-architecture-design` + `openxiangda-page` | design security gate first, then declare `src/resources/auth/<code>.json` and use `createAuthClient` / `LoginPage` |
 | 角色 / 权限组 / 字段权限 / 数据范围 / 公开访问 | `openxiangda-permission-settings` | `openxiangda permission ...` / `openxiangda settings ...` |
 | 看应用结构 / 快照 / 对比 / 诊断 / 排查 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot <APP_XXX> --profile <name> --json` |
 | 登录 / 切换平台 / profile / token / whoami | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
@@ -37,10 +38,12 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 ### Hard rules — always
 
 - ✅ Publish classic workspaces through `openxiangda workspace publish --profile <name>`; publish React SPA workspaces through `openxiangda resource publish` + `openxiangda runtime deploy`.
+- ✅ `runtime deploy` defaults to staged multipart `dist/` uploads plus a final manifest. Use `--upload-mode legacy-json` only for old platform servers.
 - ✅ User token lives in `~/.openxiangda/profiles.json`; project state in `.openxiangda/state.json` (IDs only).
 - ✅ Each profile (dev / prod / ...) has its own `appType` and resource IDs; never copy a `formUuid` / `pageId` / `workflowId` / `automationId` across profiles.
 - ✅ Run `openxiangda update check --json` at the start of substantial work; if `updateAvailable`, run `openxiangda update install` and `openxiangda skill install --force`.
 - ✅ For non-trivial app requirements, run the architecture design gate first: forms, fields, pages, permissions, data views, status/workflow, automation, notifications, and development tasks must be decided before coding.
+- ✅ For app login/auth requirements, run the auth security gate before coding: enabled methods, registration policy, identity matching keys, provider boundary, default roles, rate limits, audit fields, and third-party ownership must be confirmed.
 - ✅ For form-entry UX, pick components in this order: OpenXiangda platform form components → `antd` / `antd-mobile` wrappers → custom component only when neither exists.
 - ✅ List pages, linked options, remote selectors, and report drill-downs must use paginated server-side queries with explicit searchable fields. Do not fetch a large page and filter in local state.
 - ✅ Treat workflow forms as an exception. Ordinary ticket/order/task/asset lifecycles use status fields, state machines, action logs, permissions, and automations; workflows are for real approval tasks.
@@ -141,6 +144,7 @@ When the user provides a root domain such as `https://yida.wisejob.cn/`, use it
 - For repeated read-only multi-form queries or predefined dashboard metrics, create a data view manifest in `src/resources/data-views/`. Use `storageMode: "materialized"` for refreshed lists/reports that tolerate delay; use `storageMode: "live"` for bounded real-time joins where source changes must appear immediately. Use row views plus `sdk.dataView.query` for joined lists/lookups; use `viewType: "aggregate"` plus `sdk.dataView.stats` for count/sum/avg/min/max statistics. Add `indexes` only for materialized views. Do not use data views for single-form CRUD, simple linkedForm selects, writes, write-back, unbounded realtime joins, or ad-hoc BI. Read `references/data-views.md` before designing one.
 - For external APIs, create a connector manifest in `src/resources/connectors/` and call it from pages through `sdk.connector`; never put third-party API keys in page source.
 - For reusable backend logic shared by pages, automations, and workflows, create an App Function in `src/resources/functions/<functionCode>.json` plus `src/functions/<functionCode>/index.ts`. Call it from pages with `sdk.function.invoke`, from automation/workflow graphs with `function_call`, or from the runtime endpoint when the caller has app automation management permission. Current App Function MVP exposes controlled helpers such as `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, and `ctx.platform.api`; it does not expose raw SQL or Redis.
+- For application login, declare auth resources in `src/resources/auth/<code>.json` and publish them with `openxiangda resource publish`. App Function auth providers may validate external credentials and return only an identity assertion; they must never issue tokens, set cookies, or write platform user/binding tables directly. The platform auth service decides create/bind/reject and issues tokens.
 - Before scaffolding a real app, complex page, data management page, portal shell, status lifecycle, role governance, or automation, read `references/best-practices.md` and pick the architecture first. Prefer copying the relevant pattern from `examples/best-practices/` into `src/` instead of generating a single large page file.
 - Before publishing to another platform, verify the workspace is bound for that profile. Resource IDs from one profile must not be reused for another profile.
 - Use `openxiangda app snapshot <APP_XXX> --profile <name> --json` for diagnosis before changing an existing app.
@@ -180,7 +184,7 @@ Core CLI / state:
 - `references/architecture-design.md` — OpenXiangda architecture design gate, anti-pattern rejection, question gates, final design template, and black-box demo scenario.
 - `references/workspace-state.md` — `.openxiangda/state.json` shape and profile isolation rules.
 - `references/connector-resources.md` — `src/resources` manifests, connector schema, App Function boundary, and platform runtime calls.
-- `references/resource-manifest-cheatsheet.md` — 复制即用的 connector / data-view / notification / App Function / workflow / automation / JS_CODE / role / permission group / settings / menu manifest 骨架与运行时调用示例。在创建任何 `src/resources/` 资源前先看这份。
+- `references/resource-manifest-cheatsheet.md` — 复制即用的 auth / connector / data-view / notification / App Function / workflow / automation / JS_CODE / role / permission group / settings / menu manifest 骨架与运行时调用示例。在创建任何 `src/resources/` 资源前先看这份。
 - `references/data-views.md` — `src/resources/data-views` materialized/live data view resources, DSL, permissions, refresh, CLI commands, and runtime SDK usage.
 - `references/notifications.md` — `src/resources/notifications`, notification templates/type bindings, and `sdk.notification` / `ctx.notification`.
 - `references/best-practices.md` — initialized examples for modular pages, state lifecycles, role governance, permission isolation, high-performance queries, portal shells, workflow boundaries, and automation patterns.

package/openxiangda-skills/references/architecture-design.md

@@ -24,6 +24,7 @@ This design flow is for applications built on OpenXiangda. The output is not a g
 - status machines or workflows
 - automations, JS_CODE V2 nodes, and App Functions
 - notifications and connectors
+- application login/auth methods, registration policy, identity matching, and provider boundaries
 - publish and acceptance steps
 
 The design is complete only when another agent can implement it without deciding major architecture tradeoffs.
@@ -72,6 +73,8 @@ Do not insult the person. Criticize the proposal and explain the technical conse
 | Materialized view for hard realtime data | Users see stale data | `storageMode: "live"` only for bounded realtime joins, or direct source queries/App Function |
 | Live view for unbounded heavy joins | Slow runtime queries | Materialized view with scheduled refresh and indexes |
 | JS_CODE for reusable business service | Logic gets duplicated in graph nodes | App Function for shared backend logic; JS_CODE only for node-local trigger logic |
+| Auth provider issues tokens or writes users directly | Breaks platform account, binding, permission, and audit boundaries | Provider returns identity assertion only; platform creates/binds/rejects and issues token |
+| Phone-code login auto-registers by default | Allows uncontrolled account creation from weak identity proof | Default registration is reject; enable auto-create/whitelist only after explicit confirmation |
 | Raw native form controls | Inconsistent with platform runtime and validation | OpenXiangda platform components first, Ant Design wrappers second |
 | Multiple form permission groups without stable local codes | CLI state and platform `resourceCode` cannot reliably distinguish groups on the same form | Give every group a unique `code`, for example `ticket_reporter_view` and `ticket_repairer_view` |
 | Assuming resource publish means workflow is active | Workflow resources may exist as drafts until explicitly published | Verify `workflow list` shows `isPublished: true`; run `workflow publish <workflowCode>` when needed |
@@ -153,6 +156,20 @@ Default: reusable calculations and validations become App Functions; one-off bac
 - Are templates reusable resources?
 - Are external credentials needed? If yes, use connectors/resources, never page source secrets.
 
+### Login And Auth
+
+Ask these before generating any login/auth design:
+
+- Which methods are enabled: password, DingTalk in-app free login, CAS/SSO, phone code, guest?
+- What is the phone registration policy: reject, auto-create, bind existing only, whitelist, or manual approval?
+- What are the identity match keys and priorities: `phone`, `email`, `externalId`, `unionId`, `jobNumber`, `username`?
+- Which App Function provider validates each external credential, and what identity assertion fields must it return?
+- Which default app roles/page groups/data scopes should new users receive, if registration is enabled?
+- What are the security parameters: code TTL, send frequency, failed attempts, IP/device limits, audit fields, and failure message disclosure?
+- Is CAS/DingTalk configured by the platform tenant, or delegated to an app-level provider function?
+
+Default: registration is rejected; provider functions return identity assertions only; platform auth service owns account creation, binding, permission assignment, cookies, and tokens.
+
 ### UI Design
 
 Ask whether to use Product Design or another design skill for:
@@ -213,6 +230,14 @@ For simple CRUD/admin lists, design can proceed with the appropriate OpenXiangda
 - After publishing workflow resources, verify `workflow list` and record whether `isPublished` is true.
 - In React SPA and classic workspaces, JS_CODE/App Function TypeScript lives under `src/js-code-nodes`, `src/automations`, or `src/functions`; build with `pnpm build-js-code`.
 
+### Auth
+
+- Auth resources use stable local codes under `src/resources/auth/`.
+- Use `/view/:appType/login` or `LoginPage` from `openxiangda/runtime/react` for default React login.
+- Use `createAuthClient({ appType, servicePrefix })` for custom React login pages.
+- Phone-code providers are App Functions. They validate send/verify events and return identity assertions; they do not issue tokens or mutate platform users.
+- New-user registration must be explicit, with default roles and identity conflict behavior documented.
+
 ## Final Document Template
 
 ```markdown
@@ -262,17 +287,26 @@ For simple CRUD/admin lists, design can proceed with the appropriate OpenXiangda
 - JS_CODE V2 nodes:
 - App Functions:
 
-## 8. Notifications And Connectors
+## 8. Login And Auth
+
+- Enabled methods:
+- Registration policy:
+- Identity matching keys:
+- Provider functions:
+- Default roles/permissions:
+- Security parameters:
+
+## 9. Notifications And Connectors
 
 | Scenario | Trigger | Channel | Recipients | Template/resource | Notes |
 |---|---|---|---|---|---|
 
-## 9. Development Task Table
+## 10. Development Task Table
 
 | Phase | Task | Resources/files | Validation | Publish step |
 |---|---|---|---|---|
 
-## 10. Acceptance Criteria
+## 11. Acceptance Criteria
 
 - Functional checks:
 - Permission checks:
@@ -281,7 +315,7 @@ For simple CRUD/admin lists, design can proceed with the appropriate OpenXiangda
 - Notification/automation checks:
 - Workflow checks: real approval flows show `isPublished: true`.
 
-## 11. Open Questions And Confirmed Assumptions
+## 12. Open Questions And Confirmed Assumptions
 
 - Confirmed:
 - Still open:

package/openxiangda-skills/references/connector-resources.md

@@ -12,6 +12,7 @@ Common folders:
 - `automations`
 - `data-views`
 - `functions`
+- `auth`
 - `permissions/page-groups`
 - `permissions/form-groups`
 - `settings/forms`
@@ -33,6 +34,8 @@ Data view manifests live under `src/resources/data-views/` and define read-only
 
 App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Use JS_CODE V2 only for node-local workflow/automation scripts.
 
+Auth manifests live under `src/resources/auth/`. Use them to enable app-level login methods and bind phone-code/CAS/custom providers to App Functions. Auth provider functions are called only by the platform auth flow. They validate external credentials and return identity assertions such as `phone`, `email`, `externalId`, or `unionId`; they must not issue tokens, set cookies, or mutate platform user/binding tables.
+
 ```json
 {
   "code": "crm",

package/openxiangda-skills/references/pages/page-sdk.md

@@ -14,6 +14,7 @@ Guidelines:
 - Use `sdk.function.invoke(code, { input })` for reusable backend business logic declared under `src/resources/functions/` and `src/functions/`. Do not implement multi-form orchestration, connector fan-out, notification orchestration, or permission-sensitive backend rules directly in a page component.
 - Use `sdk.connector.invoke`, `sdk.connector.call("connector.api")`, or `sdk.connector.download` for external services. The SDK calls the platform runtime connector endpoint; it must not call third-party domains directly.
 - Use `sdk.notification.sendByType` and `batchSendByType` for reusable business messages. Custom notification types must be declared in `src/resources/notifications/` and published with `openxiangda resource publish`.
+- Use `createAuthClient` from `openxiangda/runtime` or `LoginPage` / `useAuth` from `openxiangda/runtime/react` for application login pages. Auth provider App Functions return identity assertions only; platform auth owns create/bind/reject/token decisions.
 - For the current user's department hierarchy, use `sdk.department.getCurrentUserParentDepartments()`; do not hardcode `GET /department/:id/parentDepartments` in page code.
 - Use `sdk.auth.logoutAndRedirect({ loginUrl })` for user logout when the page should return after login. It calls the platform logout endpoint, appends the current page URL as `callback`, and redirects to the login URL. Use `sdk.auth.logout()` only when the page wants to handle redirect itself.
 - Use `sdk.role.getMyRoles()`, `sdk.role.getCurrentRole()`, and `sdk.role.switchAppRole()` for current-user app role switching. Pass `roleId: ""` to switch back to all app roles.
@@ -102,6 +103,44 @@ const result = await sdk.function.invoke("reservation_reminder_summary", {
 
 Use App Functions when the logic must run server-side and be reusable by pages, automations, or workflows. Current runtime invocation requires the caller to have app automation management permission; ordinary page users should normally consume function-backed data through a permission-aware page or a narrower backend resource.
 
+Application auth:
+
+```tsx
+import { LoginPage, useAuth, useLoginMethods } from "openxiangda/runtime/react";
+
+export function DefaultLogin() {
+  return <LoginPage />;
+}
+
+export function CustomPhoneLogin() {
+  const auth = useAuth();
+  const methods = useLoginMethods();
+
+  async function submit(phone: string, code: string, challengeId: string) {
+    await auth.phoneCodeLogin({ phone, code, challengeId });
+  }
+
+  return null;
+}
+```
+
+Standalone client:
+
+```ts
+import { createAuthClient } from "openxiangda/runtime";
+
+const auth = createAuthClient({ appType, servicePrefix: "/service" });
+const methods = await auth.getMethods();
+const sent = await auth.sendPhoneCode({ phone, purpose: "login" });
+const result = await auth.phoneCodeLogin({
+  phone,
+  code,
+  challengeId: sent.challengeId,
+});
+```
+
+For phone-code auth, the App Function provider receives `event`, `appType`, `method`, `credential`, `requestId`, `request`, and `challenge`. It may return `{ ok, providerState }` for send and `{ ok, identity }` for verify. It must not return `token`, `accessToken`, `refreshToken`, cookies, or mutate platform account tables.
+
 Logout and current-user role switching:
 
 ```ts

package/openxiangda-skills/references/resource-manifest-cheatsheet.md

@@ -9,6 +9,7 @@
 - **平台 ID 由 CLI 解析**：`openxiangda resource publish --profile <name>` 把 code 解析成当前 profile 的真实 ID 并写回 `.openxiangda/state.json`。
 - **永远不写密钥**：第三方 API key、token、secret、password、authorization、headers 等绝不出现在 `src/resources/`，平台管理员在后台配置。
 - **多 profile 不共享 ID**：`dev` / `prod` 各自维护一份资源 ID 映射，复制 manifest 即可复用，不要复制平台 ID。
+- **Auth provider 只返回身份声明**：登录 provider App Function 不能发 token、写 cookie、直接改用户表或绑定表；平台按策略创建/绑定/拒绝。
 
 ## 命令
 
@@ -20,6 +21,86 @@ openxiangda resource publish  --profile <name> --prune  # 删除 manifest 未声
 openxiangda resource pull     --profile <name>          # 拉取平台资源回写到本地（用于初次同步）
 ```
 
+## 0. Auth — `src/resources/auth/<code>.json`
+
+```json
+{
+  "code": "default",
+  "name": "Default App Login",
+  "status": "active",
+  "configJson": {
+    "methods": [
+      { "type": "password", "enabled": true, "label": "账号密码" },
+      { "type": "dingtalk", "enabled": true, "label": "钉钉免登" },
+      { "type": "sso", "enabled": true, "label": "CAS", "protocol": "cas" },
+      {
+        "type": "phone_code",
+        "enabled": true,
+        "label": "手机号验证码",
+        "ttlSeconds": 300,
+        "sendFrequencySeconds": 60,
+        "maxAttempts": 5,
+        "provider": { "functionCode": "auth_phone_code" }
+      }
+    ],
+    "registration": { "mode": "reject" },
+    "binding": { "mode": "auto" },
+    "matching": {
+      "keys": ["phone", "email", "externalId", "unionId", "jobNumber", "username"]
+    },
+    "defaultRoleCodes": []
+  }
+}
+```
+
+Provider function:
+
+```ts
+export default async function authPhoneCodeProvider(ctx, input) {
+  if (input.event === "phone_code.send") {
+    return { ok: true, providerState: { nonce: "vendor-message-id" } };
+  }
+
+  if (input.event === "phone_code.verify") {
+    if (input.credential.code !== "123456") {
+      return { ok: false, message: "验证码错误" };
+    }
+    return {
+      ok: true,
+      identity: {
+        phone: input.credential.phone,
+        externalId: `phone:${input.credential.phone}`
+      }
+    };
+  }
+
+  return { ok: false, message: "不支持的认证事件" };
+}
+```
+
+React 默认页：
+
+```tsx
+import { LoginPage } from "openxiangda/runtime/react";
+
+export default function AppLogin() {
+  return <LoginPage />;
+}
+```
+
+自定义登录页：
+
+```ts
+import { createAuthClient } from "openxiangda/runtime";
+
+const auth = createAuthClient({ appType, servicePrefix: "/service" });
+const methods = await auth.getMethods();
+const sent = await auth.sendPhoneCode({ phone, purpose: "login" });
+await auth.phoneCodeLogin({ phone, code, challengeId: sent.challengeId });
+```
+
+设计前必须确认启用方式、注册策略、身份匹配键、provider 边界、默认权限、安全参数、第三方配置归属。
+
 ## 1. Connector — `src/resources/connectors/<code>.json`
 
 ```json

package/openxiangda-skills/skills/openxiangda-app/SKILL.md

@@ -64,7 +64,7 @@ openxiangda resource publish --profile <name>
 openxiangda runtime deploy --profile <name>
 ```
 
-`runtime deploy` builds and activates the app-level SPA release for `/view/:appType/*`.
+`runtime deploy` builds and activates the app-level SPA release for `/view/:appType/*`. It uploads `dist/` through staged multipart file uploads by default; use `--upload-mode legacy-json` only as an older-server fallback.
 Publish React SPA forms separately with `openxiangda workspace publish --form <formCode>`;
 with `runtimeMode: "react-spa"` this is schema-only and does not require OSS.
 

package/openxiangda-skills/skills/openxiangda-core/SKILL.md

@@ -43,7 +43,7 @@ openxiangda resource publish --profile <name>
 openxiangda runtime deploy --profile <name>
 ```
 
-`runtime deploy` builds the Vite app with a release-specific asset base, uploads `dist/` to the platform runtime release store, and activates the release unless `--no-activate` is passed.
+`runtime deploy` builds the Vite app with a release-specific asset base, uploads `dist/` to the platform runtime release store, and activates the release unless `--no-activate` is passed. The default upload mode is staged multipart file upload plus a final release manifest; use `--upload-mode legacy-json` only for older platform servers that have not been upgraded.
 
 For React SPA forms, still use targeted form publish to create/bind the form and
 sync schema:
@@ -282,8 +282,11 @@ openxiangda runtime deploy --profile prod
 It is responsible for:
 
 1. Running the workspace build command with `OPENXIANGDA_APP_TYPE`, `OPENXIANGDA_BUILD_ID`, and `OPENXIANGDA_RUNTIME_ASSET_BASE`.
-2. Uploading `dist/` to `/openxiangda-api/v1/apps/:appType/runtime/releases`.
-3. Activating the new runtime release so `/view/:appType/*` enters the React app.
+2. Uploading each `dist/` file to `/openxiangda-api/v1/apps/:appType/runtime/releases/files` with a shared trace id.
+3. Submitting the final release manifest to `/openxiangda-api/v1/apps/:appType/runtime/releases` without inline base64 content.
+4. Activating the new runtime release so `/view/:appType/*` enters the React app.
+
+Runtime upload/finalize timeout defaults to 120s. Override with `--upload-timeout-ms <ms>` or `OPENXIANGDA_RUNTIME_UPLOAD_TIMEOUT_MS`; progress and `traceId` are written to stderr, while `--json` keeps stdout as final JSON only.
 
 ## References
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.83",
+  "version": "1.0.85",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {