邮件附件下载功能解疑专题

附件下载在手机系统浏览器和 APP 内置浏览器的表现

所有的浏览器，包括 PC 和手机浏览器的下载功能，都是一样的，浏览器当捕获到某个网页应用发起的 HTTP 请求，这个请求的 content-type 是系统无法识别的（即无法打开的）就会启动下载管理器，对这个请求进行下载操作。

Android 和 iOS APP 使用内置的 webview 浏览器打开一个网页应用后，默认 webview 的下载功能是关闭的，所以点击下载按钮，无法触发下载操作，这时候 APP 应该开放 webview 的下载功能，或者自己实现一个"下载管理器"。

移动模板的附件下载功能

严格意义上，移动模板并没有所谓的什么下载功能，当用户点击"下载"按钮后，移动模板就会发起一个 HTTP 请求，浏览器或者 APP webview 捕获到这个下载 URL 之后，根据系统行为调用起下载管理器进行下载操作。移动模板仅仅能做的就是：发起一个下载 URL 的 HTTP 请求。

很多研发对接的时候，拦截到了移动模板发起的下载 URL 请求，并使用原生的下载文件方法尝试对这个 URL 进行下载操作，但是却遇到 cookie not match 的错误提示，因为如果一条 URL 就可以下载走别人的附件，岂不疯狂。

默认下载 URL 跟所有的 API 一样，是需要一对 cookie 进行鉴权的（Coremail 和 Coremail.sid），当你尝试下载的时候，必须保证发起的 HTTP 请求里面的 header 里面的 cookie 有这一对鉴权要素，并且是有效的。

你可以通过很多途径拿到这对鉴权 cookie，包括：单点的时候、webview 里面的 cookie 对象、直接调用高级 API 生成

很多研发因为各种因素，并不希望用默认采用 cookie 鉴权的方式进行下载，虽然默认的下载方式才是绝对安全的。我们也提供了一次性下载链接的方式进行附件下载，简单来说，客户研发拿到的链接是：不需要额外鉴权的、可以直接下载附件，但是是一次性的，这种方式好处是便捷，劣势是不安全，虽然链接访问一次就失效了。

可以通过自定义配置系统的enableAttachmentDownloadByToken配置进行该功能的开启，详细请看：《移动模板自定义配置系统的使用说明》

超便捷的第三方下载方式对接

客户 APP 一般采用了自身体系里面的下载方式，比如微信的 JS-SDK 里面的 wx.downloadFile() 方法。频繁的发版和对接联调，将会极大的损耗双方的时间，所以移动模板提供了大量的 API HOOK 的形式进行对接，只需要需改我们提供的外置 HOOK 文件里面的对应方法，就可以复写移动模板内置的下载方式。

详细可以查看《移动模板Hook Api文档》

邮件附件下载功能解疑专题