企业微信自建应用开发初探
1.ABC WeChat项目介绍
-
实现现有产品的登录入口，并且提供一定时间内的免登录 展示用户的排班信息 工时和异常信息的统计 请假及审批
-
第三方应用：开放体系下的第三方服务商提供； 自建应用：我们自己新建的，一般我们也都是需要自建应用进行开发。
按交互方式来分有两种：
-
主页型应用：用户点击应用后直接打开一个链接；
ABC WeChat项目属于自建应用中的主页型应用。这种应用是完全由企业自主开发定制，相对于基础应用和第三方应用更加灵活，功能上也更加符合企业自身需求。而相对于用有限几个菜单来提供响应的消息型应用来说，主页型应用的功能更加强大。
本文主要讨论自建的主页型应用。其基本结构如下图所示。
简单的集成方式
网页开发，跨平台
通过一套标准API，提供对手机硬件的调用
提供消息推送接口
提供标准页面样式库
4.开发自建应用时遇到的挑战和解决办法
本地存储
JSAPI提供的功能不够丰富
2)没有对电子围栏的支持
3)无法充分定制右上角菜单
应用安全隔离机制
2)用户访问企业应用B，假设企业应用B是恶意程序并知道Server A的相关URL，则企业应用B有机会重定向前端去访问server A；
3)根据浏览器机制，该访问会自动带上cookie A。由于cookie A中存有用户的合法认证信息，server A会认为这是一个合法访问从而执行对应的操作。而实际上该操作是用户并不知情的一个恶意操作。
没有提供集成开发工具
对自动化测试支持不足
和Facebook workplace应用开发的对比
使用和交互方式的不同
Facebook workplace中用户的使用的是对话式。用户首先会打开一个聊天窗口，在该窗口中，应用中预先提供一些菜单选项，当用户点击这些选项的时候，客户端就会发送消息给相应的应用程序后端。后端执行相应操作后会返回消息给到用户的当前聊天窗口。对于用户来说，有点像和某个对象在聊天，用户问，聊天对象回答。由于是对话式的，应用提供的菜单数量有限，可能给出的交互界面一般也不会太复杂。这样才能对用户的某个操作快速给出一个响应，符合一问一答的沟通体验。
对单点登录的支持
-
ADFS (Active Directory Federation Service) Azure AD G Suite (formerly Google Apps for Work) Okta OneLogin Ping Identity
对后台API的安全验证机制
a.前端需要调用后台API的时候，都需要先调用workplace提供的SDK获取一个签名，在获取该签名的时候，需要提供appID。每个应用都有唯一的appID。
b.前端调用后台API，并带上签名作为参数。
c.后台API接收到该请求，根据appID和相关参数重新生成签名。然后通过比对当前签名和新生成的签名是否一致来确保当前请求确实来自于同一个应用客户端。
如果应用A试图调用其他应用B的API，是无法成功的，因为A无法获取到应用B的appID，也就无法在请求中加入正确的签名。当请求到达应用B后，签名验证失败，该请求将被退回。
