0

We are currently deploying an MVC app that needs to also support a number of clients that have cookies blocked due to corporate policy. We have cookieless sessions and authentications set to autodetect because we figured out that cookieless="UseDeviceProfile" is completely unreliable since we have to support multiple browsers and Chrome (as well as IE9) craps out with this setting (UseDeviceProfile). Everything works great with the setting "AutoDetect" except for one instance:

If the user is blocking cookies and types in http://somehost.com ASP.Net adds ?AspAutoDetectCookieSupport=1 to the end of the string leaving you with a url of http://somehost.com?AspAutoDetectCookieSupport=1. When this string comes into our MVC app it blows up with a 404 error. However, if you append a "/" to the end of the initial url, as in http://somehost.com/, then everything works as expected and ASP.Net prepends the url with the session string (eg http://somehost.com/(sessionstring)/......

This will be somewhat of an edge case since the vast majority of the users will be hitting the app from a url we send to them which is not susceptible to this "bug". Additionally, the vast majority of the users will have cookies enabled as well. But we would still not like having even the small number of users this would affect see this ugly error.

Any suggestions?

Gustyn
  • 2,024
  • 1
  • 15
  • 14
  • Your question is too complex. See http://stackoverflow.com/questions/3972433/mvc2-cookieless-session-issue-using-post and http://stackoverflow.com/questions/9089745/possible-bug-with-asp-net-mvc-3-routing and http://brockallen.com/2012/04/08/cookieless-session-considered-dangerous/ for some info. Cookieless session might not be where you want to go. (I am too struggling with this.) – LosManos Mar 21 '13 at 15:31
  • Yeah, I have read all those in the past (except for the last one). Unfortunately, it is a business decision above my head. Mainly because some businesses disable both cookies and javascript as a policy and businesses are who we deal with. Cookieless is not something to implement without consideration of the risks first. Our site is working fine with it except for this one issue. – Gustyn Mar 22 '13 at 23:53

0 Answers0