#### session机制简述 在php开发过程中，保存用户登录信息时，一般会存储在session中。在微擎中重定义过session的hander，将会存储在core\_sessions表中。 php端启用session后，在响应浏览器请求时会在Header头部信息附加sessionid的值，此值是随机串，且每个用户唯一。 浏览器接收到此值时，会保存到cookie中，以便下次请求时附加上，这样用户信息就会在php端一直保持住。 #### 小程序中的session机制 小程序中并没有上面所说的浏览器的session机制，所以微擎系统自己实现了一个类似的session机制。如果在小程序中开发时，请求接口使用的是微擎提供的util.request函数，则系统会帮你附加sessionid，保持用户的session信息。 如果你没有使用微擎提供的函数，这样就需要手动来传递sessionid，也是可以在php保持session信息。 #### 小程序中使用session的好处 因为HTTP请求是无状态的，当我们请求需要用户信息时，每次请求都必须要附带上用户信息。但是这样的做法无疑是的安全隐患的，因为我们应该认同不信任GET、POST值传递过来的值。 利用session机制，用户第一次请求登录时，我们将状态保存起来，生成sessionid（可以理解为一个身份证号），下次请求附加这个sessionid，由服务器端查询得到用户数据。这样做就可以尽量保证请求安全。 当然sessionid也可通过XSS或是其实方式伪造，这不在本章讨论的范围，任何技术手段都有漏洞，我们只能是尽最大程度的提高安全门槛。 #### 手动附加sessionid 未使用微擎相关util函数时，如果还想使用session则需要手动附加传递，具体试如下： ##### 调用登录接口得到sessionid 用户进入小程序后，通过调用 wx.login 拿到 code 码，请求微擎接口 url(‘auth/session/openid’) 后，接口会返回客户端一个 sessionid，如果粉丝是老用户，则会连带粉丝信息一起返回，结构如下： ~~~ { "errno": 0, //非0时表示有错误，不会返回以下信息 "message": "", "data": { "sessionid": "c6d0d0253a8cc06e59672ae6bd165ef3", "userinfo": { //仅在老用户时会返回此数据 "fanid": "99695", "acid": "100218", "uniacid": "937", "uid": "10687", "openid": "oeR_90NUgNOhLNT84HG4weroOohk", "nickname": "", "groupid": "", "salt": "BXfVDHIq", "follow": "1", "followtime": "1524887119", "unfollowtime": "0", "tag": [ ], "updatetime": "1524887119", "unionid": "", "user_from": null }, "openid": "oeR_90NUgNOhLNT84HG4weroOohk" }} ~~~ ##### 保存sessionid，其它请求附加 客户端拿到数据后，请保存 data.sessionid 以便下次请求时使用，在构造URL时，请按以下方式附加sessionid： ~~~ http://pro.we7.cc/app/index.php?i=281&c=entry&a=wxapp&m=rcdonkey_signup&state=we7sid-(sessionid) ~~~ > 其中(sessionid) 就是要替换成上面返回数据中的data.sessionid值