遥感目录上线时，团队往往先验证“能不能搜到影像”，却漏掉更难的三件事：谁可以写入 collection，谁只能读取特定数据行，以及浏览器中看到的目录是否真正遵守同一份授权规则。FOSS4G 2026 的 eoAPI 工作坊把这些步骤连成一条本地可运行链路：从 Docker Compose 启动、地球观测数据入库和 CQL2 查询开始，再加 OpenID Connect（OIDC）、路由级与行级访问控制，最后用 STAC Browser 观察不同身份看到的目录。它的价值不在于替某个组织给出默认安全配置，而在于明确把“可搜索”与“可修改、可发现、可隔离”分别验收。
数据口径与可核查事实
FOSS4G 2026 工作坊页面将课程安排在 2026 年 8 月 30 日 13:00，时长 700 分钟，并标为中级。页面说明课程从一套完全运行在参与者笔记本上的 Docker Compose stack 开始，先把真实 Earth observation datasets 写入 eoAPI，再以 CQL2 filters 与空间搜索查询目录。
该工作坊将 eoAPI 的目录层说明为 pgSTAC + stac-fastapi-pgstac，并使用为 STAC 设计、与后端无关的 reverse proxy stac-auth-proxy 加固访问。权限链路采用 OIDC：本地 mock identity server 连接到 proxy，写入端点被 token-scoped access control 锁定，STAC Transactions Extension 只允许已授权 client 修改目录。
页面还列出 row-level authorization 的实现方向：向 CQL2 注入 filter，支持 public/private collections 与多租户数据隔离，并且无需修改底层 API。最后通过 STAC Browser 配置 OAuth2/OIDC，演示不同用户在同一 API 上发现的数据如何随授权策略变化。课程要求 Docker、Docker Compose、Python 3.10+、REST client、现代浏览器与 Git；curl 已足以完成 REST 调用练习。
这些说明是工作坊的设计与教学范围，并不证明任一生产部署已完成安全审计、容量压测或合规认证。它们足以作为生产 STAC API 的最小验收顺序。
研究的八项固定口径
-
FOSS4G 2026 工作坊安排在 2026 年 8 月 30 日 13:00，时长 700 分钟，级别为中级。
-
课程从完全运行在参与者笔记本上的 Docker Compose stack 开始。
-
工作坊将真实 Earth observation datasets 入库 eoAPI，并用 CQL2 filters 与 spatial search 查询目录。
-
eoAPI 示例由 pgSTAC 与 stac-fastapi-pgstac 组成。
-
stac-auth-proxy 被说明为面向 STAC、后端无关的 reverse proxy。
-
OIDC 通过本地 mock identity server 接入 proxy，写入端点由 token-scoped access control 限制。
-
STAC Transactions Extension 只允许 authorized clients 修改 catalog。
-
行级授权用 CQL2 filter injection 支撑 public/private collections 和 multi-tenant isolation，并在 STAC Browser 的 OAuth2/OIDC 流程中观察不同用户的发现结果。
核心机制：把目录权限分成三道可测试的门
第一道门是读取范围。用户的 token 不应只决定“能不能访问搜索”，还应决定其返回的 collection、item 与 asset 是否位于被授权的数据范围。工作坊的 CQL2 filter injection 提醒我们：行级隔离必须发生在 API 生成结果之前。前端把某项隐藏，或 Agent 在结果到手后再删字段，都不能替代服务端限制。
第二道门是写入范围。STAC Transactions Extension 涉及 collection 或 item 的创建、更新和删除，必须与只读 Item Search 分开授权。token scope 至少应区分查询、单项写入、批量入库、删除和管理；高影响写入还要绑定 collection、租户和审核日志。若一个“读取影像”的服务主体也能改写 catalog，任何提示词、脚本或凭据误配都会扩展为数据完整性事故。
第三道门是观察一致性。STAC Browser、CLI、脚本和 GIS 客户端应从相同身份策略获得结果。浏览器中看不到私有 collection，不代表其 bbox、时间范围或 item ID 没有从搜索、链接、缓存或错误信息中泄露。应将两个身份的结果差异作为固定回归样本。
GIS 场景：公共底图与项目影像共用一个目录
设想一个流域监测平台同时托管公共 Sentinel 衍生产品、多个项目组的无人机正射影像，以及尚未完成质检的应急航测数据。数据管理员可把公共 collection 设为匿名或组织只读；项目组 A 的 token 只能发现 A 的 items；入库服务主体只能向指定 collection 写入；审核角色才能把“待质检”状态改为“已发布”。
验收时不要只做管理员账号的一次成功搜索。分别以匿名、项目组 A、项目组 B、入库服务主体和审核角色调用 collection listing、Item Search、CQL2 空间过滤、单项写入与删除请求。每一例保存请求主体、scope、collection、bbox、时间窗、预期 HTTP 状态和实际返回 item IDs。项目组 A 不应通过扩大 bbox、改变 CQL2 或打开 STAC Browser 开发者工具读到 B 的 item；入库服务也不应删除或改写公共 collection。
技术路径：从本地 stack 到生产门禁
先在隔离的 Docker Compose 环境完成基线：初始化 pgSTAC 与 stac-fastapi-pgstac，入库一小份已知 footprint、时间与许可状态的测试数据，再用 CQL2 和空间搜索固定查询结果。此阶段记录 schema 版本、STAC 扩展、collection ID、item ID、资产校验值与查询样例。
随后接入 OIDC，但不把“拿到 access token”当作完成。为每一种角色创建最小 scope，依次验证：无 token 被拒绝；只读 token 只能检索允许 collection；入库 token 只能写指定目标；管理 token 的操作写入审计记录。对 Transactions Extension 加入失败路径测试，包括过期 token、错误 audience、越权 collection、重复 item、非法几何与撤销 token。
最后把 STAC Browser 放入相同身份流，选择两个测试用户比较 collection 列表、item 数量、搜索结果、直连 asset 与错误响应。浏览器只是可见的证据层；API 请求日志才应作为最终判定。上线后定期回放这些请求，并在 identity provider、proxy、STAC API 或 collection policy 变化时重新执行。
风险与局限
CQL2 filter injection 的安全性取决于实现是否把用户输入、服务端策略与查询参数正确分离。不要把客户端传来的过滤表达式直接拼接成 SQL，也不要以角色名称字符串替代经验证的 token claim。多租户隔离还需要处理缓存键、预签名 asset URL、异步入库队列、日志、备份与导出路径；仅限制搜索接口不自动覆盖这些旁路。
本地 mock identity server 适合练习 OAuth2/OIDC 流程，但它不等同于企业 identity provider 的密钥轮换、条件访问、审计留存或高可用设计。真实生产还要验证 token 生命周期、撤销、时钟偏差、反向代理 header、TLS、对象存储权限、索引性能和故障恢复。课程说明的工具与步骤是强有力的起点，不是部署完成的证明。
检查清单
-
是否为匿名、读取、入库、审核和管理角色分别保存 STAC 查询与写入样例？
-
CQL2 与空间过滤是否在服务端、结果生成前执行，并对不同租户返回不同 item 集？
-
Transactions Extension 是否拒绝无 token、过期 token、错误 audience 与越权 collection 的写入？
-
浏览器、CLI 与 GIS 客户端是否通过同一 OIDC 策略获得一致的可见范围？
-
是否验证缓存、asset URL、日志、导出和异步队列不会绕过行级隔离？
-
每次入库与策略变更是否记录 actor、scope、collection、item、时间、结果与可回滚信息？
-
identity provider、proxy 或 STAC API 升级后，是否重放最小角色矩阵而非只测管理员登录？
结论
生产 STAC API 的关键不是给目录加一次登录，而是让读取、写入和发现都受同一份可验证策略约束。eoAPI、pgSTAC、OIDC、CQL2 与 STAC Browser 组合提供了一条清晰的练习路径：先固定数据和查询，再限制写入，继而测试行级可见性和多客户端一致性。把这些测试保存成回归合同，遥感目录才不会在“可以搜索”之后失去数据边界。