5

We are getting reports from a small number of users that they are ending up on very strange paths in our web app, of the form:

https://www.example.com/(F(1xe9eXIxPzMALrZu6xd_6LBxDDlJI3lH2lkSvREZZKCfPBH20SF5EcNql6uXvyBVLgiNZshp9vXxaEzuLa5zm8c4ruux6gqu3B90eXGNmKDypu-wKR4OW_GwQctfjCdoxFYcDlLwglfE6rICL3JGkxtq4jgxggiQgJopKZGzLJ_PF2lHY7NqXya8eDshkP9o8QFDad47U54TMsxEwKCki2xPV9d9VxxjmDhNg7aQb38X_OTxHtf9I7AxiccanJf4m0bo0ceEJ70Mv20XYaMSlA2))/some/path

(Note: i've changed random chars in that in case its some kind of security leak, so don't bother trying to decode it - although if doing so might be helpful, please tell me what i'm looking for so I can do it on the real URL).

This causes a 400 in IIS, but IIS doesn't log it, so I have no idea of the referrer etc.

From what our users describe, its being caused at this step:

return Redirect("/some/path");

(which is in an ASP.NET MVC 2 Controller Action).

The site running on IIS 7.5 under SSL.

Any ideas? I've never seen anything like this :s

Update:

I also have ISAPI rewrite installed, with the following .htaccess:

RewriteEngine on
AllowOverride All

# Ensure that all traffic on the live domain is enforced as HTTPS
RewriteCond %{HTTP:Host} (.*)
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} (.*)
RewriteRule .? https://%1%2 [R,L]
abatishchev
  • 98,240
  • 88
  • 296
  • 433
Andrew Bullock
  • 36,616
  • 34
  • 155
  • 231
  • Is it happening for one particular URL's or all URLs? – Chandu Jun 03 '11 at 16:01
  • its only been reported for a single path, but you know what users are like at describing bugs, god knows whats really going on?! – Andrew Bullock Jun 03 '11 at 16:05
  • I would suggest check the cookieless attribute of sessionState element in web.config. If its tru change it to false. Again if this was the issue it should happen for all URL's.. But worth giving a try – Chandu Jun 03 '11 at 16:06

2 Answers2

7

We had exactly the same issue when browsing our site from iPads or Surface tablets. Forms authentication would switch to "UseUri" mode somehow.

As per http://msdn.microsoft.com/en-us/library/1d3t3c61(v=vs.90).aspx the default mode to store the Auth ticket in Forms Authentication is "UseDeviceProfile" which apparently checks whether the device supports cookies or not.

Then it goes and says "For devices that support cookies, no attempt is made to probe to determine whether cookie support is enabled.". Perhaps someone can help me understanding this sentence :)

In any case, we solved the issue by forcing Forms Authentication to use cookies in the web.config file:

<authentication mode="Forms">
  <forms cookieless="UseCookies" loginUrl="~/Login" timeout="2880" />
</authentication>
Yosoyadri
  • 551
  • 5
  • 8
2

Take a look at Understand How the ASP.NET Cookieless Feature Works:

In V2.0, Anonymous Identification and Forms Authentication also use this feature. The URL may now look like this: http://MySite.com/MyWebApplication/(A(XXXX)S(XXXX)F(XXXX))/home.aspx

and further down:

F(XXXX): This is the Forms Authentication ticket.

Probably some of your clients block cookies.

EDIT: That said, that URL you've posted seems excessively long. Maybe the MVC internals or the URL rewriting interact with it badly for whatever reason.

Question MVC2 Cookieless Session Issue using POST might be somewhat related.

EDIT2: This thread seems to also be related to your problem: http://forums.asp.net/t/1612673.aspx. The author mentions that

some users are reporting http 400 errors

because apparently

some users are getting forms auth tokens that are longer than normal, since these are passed in the URL they are making the URL length longer than IIS will accept

Might be a long shot, but worth a try.

Community
  • 1
  • 1
Jakub Januszkiewicz
  • 4,380
  • 2
  • 37
  • 54
  • aha! from your link: "If the combination of the anonymous identification ticket, forms authentication ticket, session ID, and user data is greater than the maximum permissible URI length, the request will fail with a 400-Bad Request error." – Andrew Bullock Jun 03 '11 at 16:31
  • how do I cause this mode to be used so i can test? just disabling cookies in FF doesnt cause it... – Andrew Bullock Jun 03 '11 at 16:32
  • True, but in the URL you posted there seems to be only the forms auth ticket, which shouldn't be _that_ long... – Jakub Januszkiewicz Jun 03 '11 at 16:40
  • its >300, 260 is the limit apparently. bloody MS – Andrew Bullock Jun 03 '11 at 16:44
  • Try to delete all cookies (from your domain), disable cookies altogether and try to authenticate in your application. If that doesn't trigger it then I think you'll need to get creative ;-) Knowing what browser your users use would probably help a lot. – Jakub Januszkiewicz Jun 03 '11 at 16:49
  • Ah, you're faster than me in posting those comments ;-) – Jakub Januszkiewicz Jun 03 '11 at 16:50
  • one report was "ive tried it on my iphone and my laptop (IE)" I can only assume the iphone was on wifi and its some network problem thats preventing cookies :s – Andrew Bullock Jun 03 '11 at 16:59