这又是一次教训，这种教训在我的职业生涯中重复过无数次，无论总结过多少次，总是在不久的将来依然再犯。现在我决定把这个教训写下来，毕竟“不过笔不进脑”，也是我经常挂在嘴边的一句话。

也是在最近的一次紧急bug修复过程中，一直在生产环境中稳定运行的基于nginx代理的cas单点登录在迁移到新的环境后，单点登录失效。通过burp进行抓包跟踪，发现返回一个302 temporary redirect，重定向后单点登录证书CASTGC cookie头丢失。本来这时查一下cas文档，就能清晰的看到下图画圈部分（cookie带着CASTGC，访问cas server）然后完成各种验证返回的302跳转中带着ticket信息，完成认证。

j

此时只要读明白这个文档流程，就可以得出结论，由于302 temporary redirect 到了一个新的域名，这意味着之前在原始域名上设置的Cookie将不再可用，而通过跟踪可以看到，302 temporary redirect 到了app的新地址，当然cookie中带着的CASTGC头信息会丢失。此时处理办法就十分的明确了：

1、通过nginx代理，将302 temporary redirect 返回的请求中写入cookie CASTGC头，如此浏览器回调时就会带入CASTGC。

2、覆写302 temporary redirect 的地址，也是通过nginx代理重写302的location 地址，让域名一致。

这两种思路在看明白文档后都能瞬间产生，这样处理过程会大为简化。也就不会有这次教训。要知道我折腾了足足2天，且险些把代码弄的一团乱。

针对这种屡次毛毛糙糙的毛病，我想引入一些原则来进行规避：

1、要冷静：当遇到问题的时候，其实立刻要控制住深入细节动手开干的“迫切之心”，这是第一要务。

2、问题回溯：要把问题回溯一遍，万万不要凭想象直接开干，回溯问题才能确认问题，也是给自己冷静下来的时间。

3、收敛范围：根据问题回溯的结果，将可能发生问题的范围进行收敛，按照最可能的地方进行优先级排序。如果条件允许，要按照2再次进行验证，最好确定问题代码段。

4、查看文档：确认自己真的理解了原理，这一步及其重要。如果涉及到中间件，如上文的cas，那么首先要搞懂这个原理、流程，按图索骥，能少走很多弯路。如果没有中间件，那么涉及的代码段的API文档，大概率要看一下，是不是有些参数用法不对，或者根本就不应该用这个API？

5、记录：问题解决不是目的，如何通过解决问题的过程提升自己的经验才是重要的，一定要进行记录，不管是经验还是技术。记录不耽误时间，忘记才是最大的浪费时间。