Canvas、Moodle、Blackboard 和 D2L Brightspace 这类学习管理系统（LMS）是大学和企业培训团队使用的主要平台。为了让 Testlify 的测评能在这些系统内使用，我作为主导工程师从零设计并构建了 Testlify 的 LTI 集成。这套集成让教育者可以直接把 Testlify 测评嵌入 LMS 课程，并自动把分数同步到成绩册中。
这套集成已**获得 1EdTech 官方认证**，认证范围为 LTI Advantage（v1.3），涵盖姓名与角色配置服务（NRPS 2.0）以及作业与成绩服务（AGS 2.0）。
我做了什么
- 自建的 LTI 1.3 安全层： 在 Next.js 14 中实现了完整的 LTI 1.3 安全规范，包括 OpenID Connect（OIDC）第三方启动流程、RSA SHA-256 JWT 签名验证，以及动态 JWKS 端点。
- LTI Advantage 服务： 在平台注册阶段将 Deep Linking 注册为支持的消息类型，构建了完整的 NRPS 2.0 集成来获取课程名册（支持分页，并在各 LMS 平台间规范化角色 URN），以及用于自动化成绩同步的 AGS 2.0 端点。
- 多租户全栈架构： 用 React 18 构建了一个多租户管理后台，为平台注册密钥配置了 MongoDB schema，并通过网络加入一个单独运行的 Moodle Docker 环境以进行本地测试。而 Canvas 由 Instructure 托管，因此直接对着一个真实运行的实例进行测试。
为什么它有意义
获得 1EdTech 的官方认证让 Testlify 得以进入高等教育和企业培训市场。自动化的名册同步和成绩回传，省去了教师手动录入数据的工作。
团队与时间线
大约 7 周内（2026 年 2 月到 3 月）共 25 次提交，与我一起共事的还有两位协作者。我写了大约 80% 的提交，并主导了架构设计和认证工作；“主导工程师”是对这个角色的准确描述，而不是夸大。
自己手写，而不是用 ltijs
ltijs 是 LTI 1.3 的标准 Node.js 库，大多数集成都会直接用它。而这个项目没有依赖它。JWKS 获取、密钥匹配和 RS256 JWT 验证都直接在这个代码库中实现，还有配套博客文章中描述的无状态会话模式：一个签名的、有效期 24 小时的会话令牌（ltik）通过 URL 携带而不是放在 cookie 里，并在每次 API 调用时作为 bearer token 发送，这样做专门是为了让集成在浏览器阻止 LMS iframe 内的第三方 cookie 时依然能正常工作。要通过 1EdTech 的一致性测试拿到认证，意味着安全层必须严格符合规范；直接掌控这部分代码，而不是依赖第三方库自己的发布节奏和对规范的理解，让这件事更容易被验证和认证。
NRPS 和 AGS 这两个被完整构建出来的 LTI Advantage 服务，做得比规范的最低要求更多：NRPS 通过 LMS 自身的 Link 请求头处理分页，并在各平台角色 URN 格式不一致时进行规范化，还带有一个客户端过滤器作为安全网，用来应对那些不完全遵循规范的 LMS 平台。
四个 LMS 平台，一套本地测试工具
Moodle 并不是由这个仓库自己的 Docker Compose 文件启动的，而是加入一个单独运行的 moodle-docker 项目的网络来进行本地测试。Canvas 是 Instructure 自己托管的 SaaS，没有对应的可本地运行的自托管镜像，因此直接对一个真实运行的 Canvas 实例进行测试。生产环境跑在 Vercel 上。早期存在过一个生产用的 Dockerfile，在 Vercel 成为唯一真正的部署目标后被删除；现在只保留了一个仅用于本地迭代的开发用 Dockerfile，而不是作为自托管的备选方案。D2L Brightspace 的支持是后来添加的，由一次有明确日期的提交为第四个 LMS 添加了注册支持，并不属于最初的三个平台。
数据模型与规模
- 每一个已注册的 LMS 平台（某个大学或机构的 Canvas/Moodle/Blackboard/Brightspace 实例）都是自己独立的租户记录，拥有自己的注册密钥，而不是共享一个全局凭据。
- 独立的服务模块分别处理符合 LTI Advantage 规范的 NRPS（名册获取）和 AGS（成绩项和分数提交），此外还有一个专门的成绩 webhook 端点。
- 平台配置和测评分配记录由通过 Mongoose 使用的 MongoDB 支撑。
这个项目的规模已经超出了自己的 README 所能覆盖的范围：一份更详细、日期也更新的内部概览文档，描述了这套集成实际演变成的样子，一个部署在 Vercel 上、支持 4 种 LMS 的完整架构，还配有自己的安全、数据库和 API 参考文档。
自研 vs 采购
手写 JWKS/JWT/会话逻辑，而不是用 ltijs 库：对于一个受认证门槛约束的集成而言，这样能完全掌控规范的符合程度，而不是继承一个依赖库自己对规范的理解。选择 Vercel 而不是自托管：一旦它成为唯一真正的部署目标，生产用的 Dockerfile 就被删除了，而不是闲置在那里不用，只留下一个仅用于本地迭代的开发用 Dockerfile。
技术栈
Next.js 14、React 18、MongoDB 配合 Mongoose、Docker Compose 用于本地 Moodle 测试，部署在 Vercel 上，通过了 1EdTech LTI Advantage（1.3）一致性测试套件认证。