集成中的安全
Filez文档中台的认证
前端集成方式
采用签名（hmac）的方式进行认证。Filez文档中台和业务系统约定密钥和加密（签名）方式。业务系统用约定的密钥对请求Filez文档中台在线编辑/预览的url进行签名。Filez文档中台收到请求后，用存储在Filez文档中台的密钥对请求的url计算签名，如果和业务系统传过来的签名一致，则认证通过。在完成认证的同时，也保证了请求的完整性（防止被篡改）。
标准集成方式
对于标准的集成方式，Filez文档中台使用委托认证的方式。当业务系统请求Filez文档中台在线编辑/预览时，Filez文档中台服务端带着业务系统传过来的认证信息回调业务系统的API。如果业务系统通过该API的认证，则Filez文档中台也通过。
分以下两种情况：
- 第三方服务与zOffice server是相同的域名。
通过Cookie。第三方服务通过Cookie从前端传递了用户的Auth info(比如：sessionId)。由于第三方服务与zOffice server是相同的域名，发给zOffice server的请求也会自动带上这些Cookie。
当zOffice需要访问第三方服务API时，会带上该用户相关的所有Cookie。
- 第三方服务与zOffice server的域名不相同
第三方调用zOffice入口API时设置上Auth token。可以在设置在url query parameter，比如 (?zdocs_access_token =xxxxx)。
当zOffice需要访问第三方服务API时，会在Cookie中带上相关的token (zdocs_access_token =xxxxx)。
采用这种方式，需要在文档中台配置三方token名。
三方验证
-
三方系统收到zOffice发来的请求，一定要做相应的Auth 验证。
-
由于url的模式比较简单，最终用户可以通过修改url来试图编辑/预览其他的文件。比如：用户正在编辑
https://oa.mycom.com/docs/app/thirdparty-rest/123/edit/content
他可以试着把123改成234,
https://oa.mycom.com/docs/app/thirdparty-rest/234/edit/content
试着去编辑234这个文件。
三方系统实现的meta API一定要验证当前请求的用户是否有权限来编辑/预览这个文件（请求meta的文件），并返回正确的值。zOffice编辑和预览任何一个文件时，都会向三方系统发meta请求来确认当前用户对这个文档的权限。用户可能是系统的合法用户，但是他不一定有权限访问三方系统中的这个文件。
集成时，可以通过编辑url上带上token来把三方系统的验证信息传给zOffice服务器（特别是跨域的情况）。一般token代表了相应的用户。如果编辑界面是一个单独的浏览器页面，用户可以轻易从浏览器的地址栏中拿到这个url并分享给别人。
从v7.1 版本开始，文档中台集成版支持前端集成方式。用前端集成的方式，调用zOffice在线编辑服务的url上需要增加时间戳。zOffice服务会检查调用请求的时间戳，可以确保某个调用请求只在短期有效。同时请求方和调用方会用相同的secret对请求进行签名，以确保请求不会被篡改。