# 会，标准整页 Redirect 模式下，Composable Storefront 会重新 Bootstrap

会。

更精确地说，在 Composable Storefront 使用 OAuth 2.1 Authorization Code Flow with PKCE，并通过当前浏览器标签页跳转到 Authorization Server 的标准实现中，原来的 Angular SPA 会离开当前 Document。认证完成后，浏览器再跳回 Storefront 的 `redirect_uri`，此时会加载一个新的 Storefront Document，并重新建立整个客户端 Angular 应用实例。

这里真正导致重新 Bootstrap 的，不是 HTML Native Form 这个控件本身，而是浏览器发生了 Top-Level Cross-Document Navigation。

整个过程可以按下面这条链路理解。

## 登录开始前，SPA 仍然正常运行

假设当前停留在购物车页面。

此时浏览器中已经存在一套完整的 Angular 运行环境，包括：

* Angular Application Injector
* 各个 Feature Injector
* NgRx Store
* NgRx Effects
* `ActiveCartService`
* `AuthService`
* `UserIdService`
* CMS、Product、Cart 等状态
* 当前组件树
* 各类 RxJS Subscription

点击登录按钮以后，Composable Storefront 会发起 Authorization Code Flow，把浏览器导航到 Authorization Server。SAP 官方文档明确将其描述为，Composable Storefront 通过重定向到 Authorization Server 来启动 Authorization Code Flow，认证完成后浏览器再被重定向回 Storefront。([SAP Help Portal][1])

这一步通常类似于：

```text
https://storefront.example.com/cart
    ↓
https://commerce.example.com/authorizationserver/oauth/authorize
    ?response_type=code
    &client_id=...
    &redirect_uri=https://storefront.example.com/...
    &code_challenge=...
    &state=...
```

一旦浏览器开始导航到 Authorization Server，当前 Storefront Document 就不再是 Active Document。原来的 Angular 组件树、JavaScript Heap、Dependency Injection 容器和内存中的 NgRx Store 实例，都属于旧 Document 的 JavaScript Realm，不能直接跟随浏览器跳转到认证页面。

HTML 标准把这种导航建模为 Document 之间的切换。新的导航会让新的 Document 取代原 Document，而不是在原 Angular 组件树里切换一个普通 Route。([HTML Living Standard][2])

所以，严格来说，甚至还没有输入用户名和密码时，原来的 SPA 就已经离开了。

## 用户名和密码表单属于 Authorization Server 页面

进入 Authorization Server 后，浏览器看到的是认证服务器提供的 HTML 页面，而不是原来的 Angular Login Component。

用户名和密码表单可能类似：

```html
<form method="post" action="/login">
  <input name="username">
  <input name="password" type="password">
  <button type="submit">Sign In</button>
</form>
```

点击提交按钮后，浏览器按照 HTML Form 的规则发起一次原生 HTTP POST。这个 POST 通常发送给 Authorization Server，而不是发送给 Composable Storefront。

认证服务器校验凭证成功后，会生成 Authorization Code，并将浏览器重定向到预先登记的 `redirect_uri`。OAuth 安全最佳实践描述的典型流程正是，用户在认证服务器页面提交凭证，认证服务器完成校验，然后将 User Agent 重定向到 Client 的 Redirect Endpoint。([IETF Datatracker][3])

典型网络链路可能是：

```text
POST /authorizationserver/login
    ↓
HTTP 303 See Other
Location: https://storefront.example.com/?code=abc&state=xyz
    ↓
GET https://storefront.example.com/?code=abc&state=xyz
```

这里推荐使用 `303 See Other`，因为它会明确要求浏览器把原来的 POST 转换成 GET，避免用户名和密码被继续 POST 到 Storefront 的 Redirect Endpoint。OAuth 安全最佳实践明确反对认证服务器使用 `307` 处理携带凭证的 POST 重定向。([IETF Datatracker][3])

## 返回 redirect_uri 时，Angular 会重新 Bootstrap

当浏览器回到下面这样的地址时：

```text
https://storefront.example.com/?code=abc123&state=xyz789
```

这不是 Angular Router 在已经运行的 SPA 内执行了一次：

```ts
router.navigate(...)
```

而是浏览器重新访问 Storefront 的 Document URL。

在纯 CSR 模式中，过程大致是：

```text
浏览器请求 index.html
    ↓
解析新的 HTML Document
    ↓
加载 runtime.js、polyfills.js、main.js 等资源
    ↓
执行 main.ts
    ↓
bootstrapApplication(...)
或
platformBrowserDynamic().bootstrapModule(...)
    ↓
创建新的 Angular Application
    ↓
创建新的 Root Injector
    ↓
创建新的 NgRx Store
    ↓
初始化认证逻辑
```

Angular 官方对 `bootstrapApplication` 的定义就是，启动一个 Angular Application 实例，并把根组件渲染到页面中。每次新的 Storefront Document 执行入口脚本时，都会产生新的 Angular Application 实例。([Angular][4])

因此答案不是只重新执行 Login Component，也不是只重新创建 AuthService，而是整个客户端 Angular 应用重新初始化。

即使浏览器的 JavaScript Bundle 来自 Memory Cache、Disk Cache 或 Service Worker Cache，这个结论也不变。缓存只减少资源下载，不会复用旧 Document 中已经存在的 Angular Injector、组件对象和 JavaScript Heap。缓存中的脚本仍然需要在新 Document 的 JavaScript Realm 中重新执行。

## SSR 模式下的说法稍有不同

如果 Composable Storefront 启用了 SSR，浏览器返回 `redirect_uri` 时，服务器可能先执行一轮 Angular Server Rendering，生成 HTML，再把 HTML 返回给浏览器。

随后浏览器加载客户端 Bundle，通过 Angular Hydration 恢复交互能力。Angular 将 Hydration 定义为在客户端恢复服务器渲染的应用，包括复用服务端生成的 DOM 结构。([Angular][5])

这种情况下，更准确的描述是：

```text
Authorization Server
    ↓ Redirect
Storefront SSR Server
    ↓ 生成新的 HTML
Browser
    ↓ 启动新的客户端 Angular Runtime
Hydration
```

它依然不是继续使用登录前的那套浏览器内 Angular Application。浏览器端仍然会建立一个新的 Angular 运行实例，只是初始 DOM 可以来自 SSR，而不是从空白页面完全重新创建。

## 返回 Storefront 后，认证代码才会被处理

新的 Angular Application 启动以后，认证初始化逻辑会检查当前 URL 中是否存在 OAuth 参数，例如：

```text
code
state
session_state
```

旧版本 Spartacus 中，这类工作由类似 `checkOAuthParamsInUrl()` 的初始化逻辑完成。SAP 官方 GitHub 问题记录明确提到，该检查会在 Spartacus 启动或返回站点时执行，然后调用 OAuth Library 的 `tryLogin()`，再处理登录状态及重定向。([GitHub][6])

简化后的逻辑可以理解为：

```ts
async function initializeAuthentication(): Promise<void> {
  const result = await oauthService.tryLogin();

  if (result && accessTokenExists()) {
    userIdService.setUserId('current');
    store.dispatch(loginAction());
    authRedirectService.redirect();
  }
}
```

Authorization Code Flow with PKCE 中，还会使用先前生成的 `code_verifier`，配合返回的 Authorization Code 请求 Token Endpoint：

```text
POST /oauth/token

grant_type=authorization_code
code=abc123
redirect_uri=https://storefront.example.com/
client_id=...
code_verifier=...
```

只有成功换取 Access Token 以后，Composable Storefront 才会把用户状态切换成 `current`，加载用户资料，并触发活动购物车加载或匿名购物车合并。

所以观察 Redux DevTools 时，登录后的 Store 很可能表现为一棵新创建的状态树，而不是在登录前那棵 Store 上简单追加一个 `Login Success`。

## 为什么登录后的购物车会出现重新加载和 Merge Cart

登录前的匿名购物车可能存在于后端，也可能有部分身份信息保存在浏览器持久化存储中。但登录前那个 NgRx Store 实例已经随着旧 Document 离开。

新 SPA Bootstrap 后，购物车模块需要重新确定：

```text
当前 User ID 是 anonymous 还是 current
匿名 Cart ID 或 GUID 是什么
注册用户是否已有 Active Cart
是否需要 Load Cart
是否需要 Create Cart
是否需要 Merge Cart
最终哪个 Cart 应成为 Active Cart
```

这就能解释上一张 Redux DevTools 截图中的行为序列：

```text
[Cart] Clear Cart State
[Cart] Set Active Cart Id
[Cart] Merge Cart
[Cart] Create Cart
[Cart] Create Cart Success
[Cart] Remove Cart
[Cart] Merge Cart Success
[Cart] Set cart data
```

不能把这些 Action 理解成旧 SPA 在整个认证跳转过程中始终存活。更符合浏览器生命周期的理解是，新 SPA 返回并 Bootstrap 后，根据持久化的匿名购物车标识、当前用户状态及后端结果，重新构造 Cart State，然后执行 Cart Merge。

其中可以被保留下来的通常是浏览器持久化资源，例如：

```text
Cookie
localStorage
sessionStorage
IndexedDB
浏览器 HTTP Cache
Service Worker Cache
后端保存的 Cart
```

不会自然保留下来的是：

```text
旧 Angular Service 实例
旧 Component 实例
旧 Injector
旧 RxJS Subscription
旧 NgRx Store 内存对象
旧 JavaScript 变量
旧页面 DOM
```

某些 NgRx State 可能通过 State Persistence 机制从 Storage 恢复，但那属于新 Store 创建后的 Rehydration，不是旧 Store 实例继续运行。

## 返回登录前页面的跳转通常不会再次 Bootstrap

认证完成并换取 Token 后，`AuthRedirectService` 通常会读取登录前保存的 URL，例如购物车页面，然后通过 Composable Storefront Routing Service 或 Angular Router 返回原页面。SAP 官方项目记录显示，`AuthRedirectService` 会保存 Redirect URL，并在登录成功后通过 Routing 导航回该地址。([GitHub][7])

这里需要区分两类 Redirect。

浏览器级 Redirect：

```text
Storefront → Authorization Server
Authorization Server → Storefront redirect_uri
```

它们属于 Cross-Document Navigation，会造成 SPA 重新启动。

Angular Router Redirect：

```text
/redirect-callback → /cart
```

它通常属于 Same-Document Navigation，只替换页面中的组件，不会重新执行整个 `main.ts`，也不会重新创建 Root Injector。Angular 官方对 SPA 路由的描述正是，只更新页面的一部分来呈现目标视图。([Angular][8])

因此，一次正常登录通常可以抽象为：

```text
旧 SPA 实例
    ↓ 浏览器整页导航
Authorization Server 登录页面
    ↓ Native Form POST
Authorization Server
    ↓ HTTP Redirect
新 SPA 实例 Bootstrap
    ↓ 处理 Authorization Code
获取 Access Token
    ↓ Angular Router
返回登录前页面
```

整个流程通常只有返回 Storefront 时发生一次新的客户端 Bootstrap。后续从 Callback URL 跳回 Cart、Checkout 或 My Account 页面，只要使用 Angular Router，就不会再次完整 Bootstrap。

## Native Form 不是唯一判断依据

即使 Authorization Server 的登录页面不用 Native Form，而是用 JavaScript 发起 Fetch，认证完成后只要执行：

```ts
window.location.href = redirectUri;
```

或者返回：

```http
HTTP/1.1 302 Found
Location: https://storefront.example.com/
```

仍然会产生新的 Document，SPA 依然需要重新 Bootstrap。

反过来，即使使用 Native Form，只要表单提交发生在 Popup Window、Iframe 或其他独立 Browsing Context 中，主窗口里的 SPA 就可能继续存活。

SAP 官方 Spartacus 项目曾讨论过在 Popup 中完成 Authorization Code Flow，讨论中明确说明，当时支持的是重定向到认证页面，而 Popup 方案需要在认证成功后通知主窗口更新用户状态。([GitHub][9])

所以判断标准可以写成：

```text
是否在当前主标签页发生了 Cross-Document Navigation
```

而不是：

```text
是否使用了 HTML Form
```

## 可以在项目里直接验证

可以在 `main.ts` 的 Bootstrap 入口加入一个跨页面计数器：

```ts
const key = 'spa-bootstrap-count';

const count =
  Number(sessionStorage.getItem(key) ?? '0') + 1;

sessionStorage.setItem(key, String(count));

console.log('[SPA bootstrap]', {
  count,
  href: window.location.href,
  time: new Date().toISOString(),
});

bootstrapApplication(AppComponent, appConfig).catch((error) => {
  console.error('Angular bootstrap failed', error);
});
```

登录前控制台可能显示：

```text
[SPA bootstrap] count: 1
```

从 Authorization Server 返回后会显示：

```text
[SPA bootstrap] count: 2
```

由于普通 Console 在页面跳转时会被清空，需要在 Chrome DevTools 的 Console 或 Network 面板中打开 `Preserve log`。

Network 面板可以筛选 `Doc`，正常会观察到：

```text
storefront document
authorize document
login POST
redirect
storefront document
token request
```

返回 Storefront 时出现新的 `document` 请求，就是重新加载页面的直接证据。即便响应标记为 `memory cache` 或 `service worker`，只要产生了新的 Document 和新的 JavaScript 执行上下文，Angular 仍然会重新 Bootstrap。

归纳成一句话，在 Composable Storefront 标准 OAuth 2.1 Authorization Code Flow 中，只要登录过程占用了当前主标签页，并从 Storefront 跳转到 Authorization Server，再通过 `redirect_uri` 跳回 Storefront，浏览器端的 Angular SPA 就会重新 Bootstrap。Native HTML Form 只是认证服务器收集凭证的方式，真正让 SPA 重启的是整页跨 Document 导航。

[1]: https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/dc307a52881548e9a15aa6fcba6f7587.html?utm_source=chatgpt.com "Session Management"
[2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html?utm_source=chatgpt.com "7.4 Navigation and session history"
[3]: https://datatracker.ietf.org/doc/rfc9700/ "
            
        RFC 9700 - Best Current Practice for OAuth 2.0 Security

        "
[4]: https://angular.dev/api/platform-browser/bootstrapApplication?utm_source=chatgpt.com "bootstrapApplication"
[5]: https://angular.dev/guide/hydration?utm_source=chatgpt.com "Hydration"
[6]: https://github.com/SAP/spartacus/issues/14694 "Code Auth Flow causes incorrect redirection when opening new tabs · Issue #14694 · SAP/spartacus · GitHub"
[7]: https://github.com/SAP/spartacus/issues/13945?utm_source=chatgpt.com "Issue #13945 · SAP/spartacus"
[8]: https://angular.dev/tutorials/first-app/10-routing "Add routing • Angular"
[9]: https://github.com/SAP/spartacus/issues/9555 "Support Implicit and Authorization Code Flow in popup · Issue #9555 · SAP/spartacus · GitHub"


更精确地说，在 Composable Storefront 使用 OAuth 2.1 Authorization Code Flow with PKCE，并通过当前浏览器标签页跳转到 Authorization Server 的标准实现中，原来的 Angular SPA 会离开当前 Document。认证完成后，浏览器再跳回 Storefront 的 redirect_uri，此时会加载一个新的 Storefront Document，并重新建立整个客户端 Angular 应用实例。

Oauth 2.1 authorization code flow login 会导致 SPA 重新加载？

更精确地说，在 Composable Storefront 使用 OAuth 2.1 Authorization Code Flow with PKCE，并通过当前浏览器标签页跳转到 Authorization Server 的标准实现中，原来的 Angular SPA 会离开当前 Document。认证完成后，浏览器再跳回 Storefront 的 redirect_uri，此时会加载一个新的

紫薇堂堂主

开发工具

网络与通信

安全

ComposableStorefront在OAuth2.1授权码流程中，浏览器整页跳转会导致Angular应用重新初始化。认证完成后返回Storefront时，会加载新文档并重新创建Angular运行环境，包括组件树、NgRx状态和依赖注入容器。这一过程是浏览器跨文档导航的结果，而非表单提交本身导致。

代码解释

服务器

容器

路由

GitHub

OAuth

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Oauth 2.1 authorization code flow login 会导致 SPA 重新加载？-腾讯云开发者社区-腾讯云

Oauth 2.1 authorization code flow login 会导致 SPA 重新加载？

Oauth 2.1 authorization code flow login 会导致 SPA 重新加载？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐