微信小程序中模拟 cookie 的实现方式探讨

本篇文章主要介绍了微信小程序中模拟 cookie 的实现方式探讨，内容挺不错的，现在分享给大家，也给大家做个参考。

开发背景

现有系统已经有一套完整的接口，用户状态、验证都是基于 cookie 的。

部分业务要上小程序版本，众所周知，微信小程序不支持 cookie 的。要上线的业务，最好的方式还是基于现有这套接口做，改动不大，也最快。

模拟 cookie

点击-“系统优化工具,一键解决电脑卡顿”；

通过浏览器的开发工具，Network 栏查看请求，浏览器中的 cookie 会携带在每个 http 的 Request Headers 里面，用 Cookie 作为键名。

那么，在微信官方请求方式 wx.request 中，我们设置 header，添加一个 Cookie 应该可以得以模拟。

问题又来了，怎么获取到服务器返回的 cookie 呢。

通过登录接口(登录的时候，服务器端会植入 cookie 作为 session)，查看 http 返回头。

拿到 cookie 存入本地中，下次请求数据的时候直接塞进去，完美。

格式化 cookie

原本以为 cookie 只需要一进一出就可以完美模拟，实际操作才发现，携带上去的 cookie 服务器无法识别。

服务器返回的 cookie 中，会携带上很多储存用的字段，例如 path=/;

妈耶~要怎么过滤呢。

简单粗糙的写了一个过滤方案。

csrfToken 是接下来配合 Egg.js 用的，Path=/; 在某些应用下会是 path=/;

normalizeUserCookie 主要是过滤了 xx=xxx; 这样的数据，然后排除 path=/; 这样无意义的数据。

在登录接口的时候，存上 cookie，在接下来的请求中带上，那么，应该、没错、可能、可以模拟了。

配合 Egg.js

Egg 内置的 egg-security 插件默认对所有『非安全』的方法，例如 POST，PUT，DELETE 都进行 CSRF 校验。
Egg.js 虽然可以在配置中关闭 CSRF，但是，如果一定要使用呢？

首先，要弄明白一件事，csrfToken 怎么来的。

经过多次验证得知，当 http 请求时，在约定位置没有携带上 csrfToken 值，此次请求会在返回的 cookie 中携带上一个新的 csrfToken；当本次请求已携带上值，就不会产生成 csrfToken。当约定位置带上的 csrfToken 与 cookie 里面的 csrfToken 一致时，通过验证。

接上面的 格式化用户需要的 cookie 操作，先抛开 csrfToken 单独处理用户状态等。

在每次请求结束后，试着单独拿 cookie 中可能存在的 csrfToken，有值就缓存，没值跳过用旧值。

封装一个 Ajax

本次小程序是基于 wepy 的，所以使用了优化后的 wepy.request;

基于 Egg.js 的版本。

可能与实际开发有点出入，适当修改。

以上就是微信小程序中模拟 cookie 的实现方式探讨的详细内容！

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。