记接口当中使用 session 是如何被排斥的
第一次在 Laravel
的接口当中使用 Session
,受到成吨的伤害。
话不多说,直奔主题吧。
使用的代码是刚通过 composer create-project --prefer-dist laravel/laravel blog
安装的。
首先先来调用下 Session
,路由为 api.php
中的接口路由,并在首页 welcome.blade.php
中使用 JQuery
的 $.get()
来访问下该接口。
访问下看是否设置成功。
这样应该是设置成功了吧,再加点判断,看下客户端能不能找到 Session
。
看下结果。
What ?为啥没找到我的我名字呢?通过读文档知道还有另一种写法,我们再来尝试下看看。
再看下结果。
Emmmm...直接报错了,有点过分了吧。直接 Google
报错信息发现,Laravel
中的 Session
被封装了,要使用 Session
必需要开启 Session
中间件。而默认 api
中没有开启该中间件,如下图所示。
大家有没有在 web
中看到 \Illuminate\Session\Middleware\StartSession::class
这个中间件,从字面意思应该很清楚了吧?这个就是开启 Session
的中间件,让我们加在下面的 api
中再尝试下。
没报错了,但是好像还是获取不到上一次请求设置的 Session
啊,灰常尴尬。让我们从客户端获取服务端 Session
的原理开始思考,大家应该都知道,Session
在设置时,会伴随 Cookie
在客户端的生成,当客户端请求时会带上设置好的 Cookie
,一般存的是 session_id
,服务端拿到这个 session_id
后就能顺利拿到 Session
。那我们能设置只是找不到,会不会是 Cookie
出错了呢?所以让我们看看接口响应的 Cookie
。(PS:我设置了 .env
中的 SESSION_LIFETIME
为24小时,这里就不多赘述了,并且为了区别,我设置了 APP_NAME
为 test
以区分 Laravel
自己生成的 Cookie
)
这里主要看是否有 Value
和 Expires
,都有值且过期时间为1天,不存在秒过期的情况。那是为什么呢?
各位,请仔细看 Request
中的 Cookie
与响应 Response
的 Cookie
,有没有发现 Value
有很明显的差别,完全不像是一个应用生成的 Cookie
,并且当你刷新页面时原本 Request
中的 test_session
应该替换为上一次请求中的 Response
中的 test_session
,这样就能找到之前设置好的 Session
了,但实际是又重新生成了一个不同的 Cookie
。那么问题很明显了,设置 Session
返回的 Cookie
是有误的,导致框架每次加载时,判断这个 Cookie
为无效的并重新生成了一个新的,所以找不到之前的 Session
。
让我们又回到中间件那里。
我在 web
中又发现一个 \App\Http\Middleware\EncryptCookies::class
,字面意思,一个 Cookie
加密中间件。好像跟我们的问题有关系诶,我已经将它添加到 api
中,我们再试一下。
哎哟,终于好了,接口里面使用 Session
就这样被排斥吗 :cry:
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: