CODEWITHSUNDEEP
iisasp.net-mvc-5owinurl-encodingasp.net-identity-2
Tim Coulter
Tim Coulter

Reputation: 8937

ASP.NET MVC5 OWIN rejects long URLs

I am creating an ASP.NET MVC5 action method that implements a password reset endpoint and accepts a click-through from an email message containing a token. My implementation uses OWIN middleware and closely resembles the ASP.NET Identity 2.1 samples application.

As per the samples application, the token is generated by UserManager and embedded into a URL that is sent to the user by email:

var token = await UserManager.GeneratePasswordResetTokenAsync(user.Id);
var encoded = HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes(token));
var uri = new Uri(Url.Link("ResetPasswordRoute", new { id = user.Id, token = encoded }));

The link in the email message targets an MVC endpoint that accepts the token parameter as one of its route segments:

[Route("reset-password/{id}/{token}"]
public async Task<ActionResult> PasswordResetAsync(int id, string token)
{
    token = Encoding.UTF8.GetString(HttpServerUtility.UrlTokenDecode(token));

    // Implementation here
}

However, requests to this endpoint (using a URL generated in the above manner) fail with Bad Request - Invalid URL.

It appears that this failure occurs because the URL is too long. Specifically, if I truncate the token segment, it connects correctly to the MVC endpoint (although, of course, the token parameter is no longer valid). Specifically, the following truncated URL works ...

http://localhost:53717/account/reset-password/5/QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFE

... but it will fail if one additional character is added ...

http://localhost:53717/account/reset-password/5/QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFEf

I believe that the default IIS configuration setting for maxUrlLength should be compatible with what I am trying to do, but I have also tried explicitly setting it to a larger value, which did not solve the problem.

However, using Fiddler to examine the server response, I can see that the working URL generates a server response with the following header ...

Server: Microsoft-IIS/8.0

... whereas the longer URL is rejected with a response containing the following header ...

Server: Microsoft-HTTPAPI/2.0

This seems to imply that the URL is not being being rejected by IIS, but by a middleware component.

So, I am wondering what that component might be and how I might work around its effect.

Any suggestions please?

Many thanks, Tim

Note: Although my implementation above Base64 encodes the token before using it in the URL, I have also experimented with the simpler approach used in the sample code, which relies on the URL encoding provided by UrlHelper.RouteUrl. Both techniques suffer from the same issue.

Upvotes: 2

Views: 763

Answers (1)

Dmitry S.
Dmitry S.

Reputation: 8513

You should not be passing such long values in the application path of the URL as they are limited in length to something like 255 characters.

A slightly better alternative is to use a query string parameter instead:

http://localhost:53717/account/reset-password/5?token=QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFEf

That should be safe for at least 2000 characters (full URL) depending on the browser and IIS settings.

A more secure and scalable approach is to pass a token inside an HTTP header.

Upvotes: 4

Related Questions