This repository was archived by the owner on Nov 20, 2018. It is now read-only.
This repository was archived by the owner on Nov 20, 2018. It is now read-only.
Reevaluate behavior when cookie parsing fails #515
Closed
Description
Related to issue #390 but this topic is more about what the behavior should be when you're in this state.
I ended up with request cookies like the following for http://localhost:5000/:
__RequestVerificationToken=xhhkbQ7Vw0bBpyKt924bA4mEwn-xqrEj8w_Icr5Z2LQnXtugI8qt_glxLRAP3KPQR8RGBUukjfQzPOFCO2sffThjcUmtdgSkzn2iZ4NoObo1;
rm3EK3lo-DQ=CfDJ8DZcqGjS2eNPqurEN8WnNPUoyWWl9b3SROeJgbx_QsBsWViYvx7lI8jIQf5nv9_3B8zVdvmQdTYuqACH5p9Lx07aH8sctN-kt6CJTA4pp39O2Yymvs7M2IBx8eeTqeEn5uXh9_yV66f6dqK4l78r7dQ;
Sample=36;
ipt={"v":{"L":3},"pt":{"d":3},"ct":{},"_t":44,"_v":"2"};
.AspNet.Session=f5b61640-9efc-a9f8-32c1-6291f903f795;
BQFxCZqo5n4=CfDJ8GVk6iB7ymZKmY1csOqk7Cds8G0Hd8XFeWgB9u4RB0r73u2gJvYuQmjGY2vn8WtGvFFKwUOLS3LVlkIxH9YmvQBopm69anm0VuXYBePCzYMYRruxRQ9ma34AAZSI76o3eV6cV0xsU3MYytMgTkC_f1U;
eZYsIZozZe4=CfDJ8GVk6iB7ymZKmY1csOqk7CeNhzXg8fanKIOAcxGcBWXzm5AYBDlOgfSNHG8dLtWG2bFucr_PNhmjyEybiZQgGrdL2CEmvrhxR4MIoh6FgXdcx7N6OHL0tgDn520ud3i-ODYlXGr3aYT-5Eg3M8ulwvc;
XSRF-TOKEN=CfDJ8GVk6iB7ymZKmY1csOqk7CfYDif53fpXVX_mfM1SVKdA4fDDMi3rx98lBVks-zLiGjMv3j6SgAEHMe4VwKqMw5WCdJObXVgF1kTLA62U8SQJ2eLK2cv4vhcmlixQN3dhtOt_yeiPYtAkipDlhPUWiAg
and I was mystified about what to do when antiforgery wasn't working. At some point in my otherwise squeeky-clean past, I was hacking on something that added ipt={"v":{"L":3},"pt":{"d":3},"ct":{},"_t":44,"_v":"2"};
to my cookie store, and it effectively 'poisoned' local development for me with anything that relies on cookies in our stack.
What happens when you get into this state is that there's no indication that the cookie header was consider invalid, the cookie collection is empty, and no exception is thrown.