It turns out that in .net 2.0, the base "Mozilla" rendering profile sets the cookies capability to false. Why would it do this? Well, specific mozilla-derived browser profiles turn the setting back on, so it's not like asp.net thinks Firefox won't support cookies. Here's a clue, in the comments at the top of the mozilla.browser config file, showing some sample user agent strings that would match:
<!-- sample UA "Go.Web/1.1 (UP.Browser/3.1-UPG1 UP.Link/3.2; Mozilla/1.0; RIM957; Elaine/1.0 )" -->
<!-- sample UA "Mozilla/1.0[en]; Go.Web/1.1 (compatible; MSIE 2.0; HandHttp 1.1; Palm)" -->
Some old school mobile browsers were the targets here. Unfortunately, if users come to your site on, say, a Samsung Blackjack or another new device running WM5 and PIE, they end up in the same bucket. You can sniff this out by logging Request.UserAgent, Request.Browser.Browser, and Request.Browser.Type. I highly recommend doing this at least on one "entry" page for any mobile site. You may also want to log the computed capability for an attribute your app needs, like cookies (Request.Browser.Cookies).
Even though asp.net will automagically try to do cookieless sessions, I want to force cookie-based authentication on my mobile site so that users don't have to sign in every time they visit (those extra key presses are brutal on a phone). I know that more or less every mobile browser out there can support cookies now, so I'm not too worried about this decision.
The fix? Similar to the others, we'll just override this one attribute in our supplement.browser file:
<browser refID="Mozilla">
<capabilities>
<capability name="cookies" value="true" />
</capabilities>
</browser>
Another free bonus is that with cookies, asp.net doesn't have to do the URL mangling that is involved in cookieless techniques. So your users get URLs that make more sense in their history and work properly as bookmarks!
No comments:
Post a Comment