通常API接口保护有以下几种：使用HTTPS防止抓包，使用https至少会增加破解者抓包的难度。加解密，通过md5加密数据+时间戳+随机串（salt），然后将MD5加密数据、时间戳、原始数据传给后台。背景指定有效持续时间。如果数据与原始数据一致，则认为是正常请求；也可以使用aes/des等加密算法，也可以加入客户端的本地信息作为判断依据。本地加密混淆，上面提到的加解密数据和算法，不要直接放在本地代码中，因为容易被反编译破解，建议放在独立的模块中，越混淆越多函数名，越难读越安全。User-Agent和Referer限制api保护的登录验证，包括设备验证和用户验证。可以通过查看session来判断用户是否登录api。限制定期监控，查看日志，检测异常接口访问。在开发web端程序的时候，如果你的服务是放在外网的，你不能完全阻止别人模拟客户端调用你的webapi。因为你所有的前端代码用户都可以直接或间接地看到它。开发小程序项目时，前端小程序代码上传到微信服务器，其他人较难直接看到或获取源代码，因此小程序端相对安全。为什么要做接口保护和权限校验？有时，黑客可以通过抓包等方式获取后台接口信息。如果不进行权限验证，黑客可以随意调用后台接口篡改数据和服务器。攻击。因此，为了防止恶意调用，后台接口的保护和权限验证非常重要。如何保护小程序的界面？保护小程序的界面，首先需要了解小程序的登录流程，如下图所示：整个流程如下：backgroundServer后台服务器使用小程序的appid、appsecret和code，调用微信接口服务换取session_key和openid（openid可以理解为每个用户在小程序中的唯一标识号）。后台服务器自定义生成一个3rd_session，作为openid和session_key的key值，后者作为value值，在后台服务器或者redis或者mysql中保存一份，同时将3rd_session传给小程序。小程序收到3rd_session后，保存到本地缓存，比如wx.setStorageSync(KEY,DATA)后续小程序用3rd_session向后台服务器发送请求，可以放在header中，也可以放在body中。后台服务器以3rd_session为key，在3rd_session未过期的情况下读取其值（即openid和session_key的组合值），通过openid判断是哪个用户发送了请求，然后与发送的body进行比较value（如果有），调用后台逻辑处理业务数据返回给小程序ps：sessionkeysession_key是用户数据加密签名的密钥为了保护应用程序自身的数据，开发者服务器不应将会话密钥传递给小程序，也不应将此密钥提供给外界。session_key主要用于wx.getUserInfo接口数据的加解密，如下图：什么是sessionId？在微信小程序开发中，每次wx.request()发起的请求对于serversession都是不同的。你是什??么意思？也就是说，与浏览器不同，小程序的每一次请求，都相当于被不同的浏览器发出。即不同请求之间的sessionId是不同的（其实小程序cookie是不携带sessionId的）。如下图所示：实际上，小程序的每次wx.request()请求都不包含cookie信息，即没有sessionId信息。那么我们能否实现类浏览器访问，将session保存到后台服务器呢？答案是肯定的。我们可以在每个wx.request()的头部添加##java。jsessionid只是tomcat对sessionId的命名，其实就是sessionIdheader:{'Cookie':'JSESSIONID='+sessionId}##thinkjs3.0header:{'Cookie':'thinkjs='+sessionId}这样写的效果是如下图所示：在thinkjs3.0的后台代码中，sessionId保存在cookie中，可以通过：constsession_id=this.cookie('thinkjs')提取sessionId的值。ThinkJS的具体实现代码首先创建服务端代码，如下图：cd到根目录，运行：thinkjsnewserver创建后台代码：
