如何在无Cobalt的2016版Office Online WOPI服务器禁用文档同时编辑

我来帮你捋清楚这里的核心问题——你对WOPI锁机制的预期没错，但Office Online 2016版的默认行为需要你在服务器端做严格的锁状态校验和响应控制，才能实现“禁止后续用户打开编辑”的效果，而不仅仅依赖Lock接口返回409。

首先，你可能忽略了这几个关键细节： #

• Lock接口返回409时，必须携带响应头：当用户B请求锁但文档已被锁定时，你的服务器不仅要返回409状态码，还必须在响应头中带上X-WOPI-Lock（当前有效的锁值）和X-WOPI-LockFailureReason（比如明确说明“文档已被其他用户锁定”）。如果缺少这两个头，Office Online会无法正确识别锁冲突，仍允许用户进入编辑模式。
• CheckFileInfo是第一道关卡：Office Online在打开文档前会先调用CheckFileInfo接口，这是你阻止编辑的最佳时机。如果文档当前有有效锁，你需要在CheckFileInfo的返回值中设置ReadOnly: true和UserCanWrite: false，这样Office Online会直接以只读模式打开文档，用户根本无法进入编辑状态，也就不会出现后续的共同创作提示。

你必须单独实现完善的锁机制 #

WOPI规范只定义了锁的接口协议，但锁的状态管理完全需要服务器端自己实现。结合你使用的WOPIFramework，你需要做这些修改：

1. 维护锁的状态：为每个文档存储当前的有效锁信息，包括锁值、锁定用户标识、过期时间（WOPI锁默认有租期，需要处理续租）。因为你不用SQL，可以用内存缓存（比如字典+定时器）来临时存储。
2. 完善Lock/RefreshLock/Unlock接口：
   • Lock：检查文档是否有有效锁，没有则生成唯一锁值并存储，返回200；有则返回409并携带锁相关响应头。
   • RefreshLock：接收到合法的锁值时，更新锁的过期时间，返回200；锁无效则返回409。
   • Unlock：收到合法锁值时，删除对应的锁记录，返回200；锁无效则返回409。
3. 修改CheckFileInfo逻辑：在返回文件信息前，先检查文档是否有有效锁，如果有，就把ReadOnly和UserCanWrite设为false，同时可以添加Lock字段返回当前的锁值，让Office Online能准确识别状态。

额外提示 #

如果想更严格地阻止用户打开文档（而不是只读），你可以在CheckFileInfo接口直接返回403 Forbidden状态码，但这种体验可能不太友好，一般建议还是返回只读模式并提示用户文档已被锁定。

按照这个思路调整你的WOPI服务器实现后，当用户A正在编辑文档时，用户B打开文档会直接进入只读模式，无法发起编辑操作，也就不会出现内容被覆盖的问题了。

内容的提问来源于stack exchange，提问作者Nikolay