您的足迹:首页 > 语言程序 >谁动了我的 Token

谁动了我的 Token

这里涉及到的系统是一个 7 年的遗留系统(技术栈是 .NET MVC2),即将被客户淘汰。这篇博文的主题无关技术本身,文中谈到的技术细节也不是什么高大上的,更多的是想记录因这件事情触发的非技术思考。

早上7点45分来到公司,我坐在办公桌旁边开始考虑今天的工作事项。想到客户一直抱怨的电子表单系统在产品环境上8000多个无法重现的错误日志就亚历山大,“替换成微软类库也并不一定解决问题,客户又在捣乱。今天一定要和夏夏一起看看这个问题,优先级得提上来”,我心里暗自的想着,并把它加到了待办事项的第一条,优先级标为高,截止时间是今天。

开了个好头,但遭遇IE-Only问题

开完早会,我和夏夏了解了问题上下文,然后开始分析错误日志。我俩惊讶的发现,其中7000多条错误日志是发生在表单导航部分!夏夏说,“就先从它开始吧。” 我俩很快统一思路,瞄准这几个页面就开始搭建环境尝试问题的复现。

按下遇到的各种环境问题不提,这个错误很快就在IE浏览器(文中统称IE)上重现了,而且只在IE上才有这个问题:页面缺少Anti-CSRF Token导致请求被拒绝。“哎,这不错!”,夏夏用他一贯的幽默风格说道。我想:是的,好兆头,万事开头难,我们似乎开了个好头,然而这怎么好像又是IE啊,真不靠谱。

更不靠谱的e.preventDefault?

时间已经转眼到了10点半,我们开始尝试定位代码,寻找问题的根源。咦,貌似看起来页面前进后退的按钮触发了Form的POST请求,而服务端收到的请求中并没有Token。那么“我们页面AntiCSRF Token是怎么产生的呢?”我问夏夏,夏夏说:“娴静,你看这个js文件”。

相关推荐

发表评论

路人甲 表情
Ctrl+Enter快速提交

网友评论(0)

关于我们 - 联系我们 - 留言反馈

站内所有资源仅供学习与参考,请勿用于商业用途,否则产生的一切后果将由您自己承担!

免责声明:本站所有内容来源于互联网。如果本站部分内容侵犯您的权益,请您告知,站长会立即处理。

Powered by emlog

京ICP备15021761号-1

sitemap