kmcnamee
kmcnamee

Reputation: 5255

Getting the # route in from the Request in a controller in ASP.Net MVC

I have an ASP.Net MVC web site using Forms authentication, with the loginUrl set to a Url which is used for authentication in the web.config. The login process calls the login controller which goes through a SSO process where it does a redirect etc and the log process works correctly the user can login etc. As part of the login process I use the returnUrl to send the user to the page they initially requested. Or the default if none is specified.

If the user types in a Url to another page such as http://mysite/help the returnUrl is as expected /help. However if the user enters a url containing a hash route like http://mysite/#/test/123 the returnUrl is simply / . Is it possible to get the full url with the #/test/123 from within the controller?

To isolate this problem I created a simple ASP.Net MVC web project that demonstrates this behavior and as you can see the # route is missing when the controller is called:

Here is the web.config:

web.config

Here is the request in the browser:

enter image description here

Here is the debug view of the test application where you can see the ReturnUrl is just / and the RawUrl just has the querystring.

enter image description here

Here is the same in fiddler:

enter image description here

Here is the redirect to the login url in chrome. As you can see the # portion of the URL is somehow preserved in the sample app even though its not present in request in the controller and i don't see it in fiddler.

enter image description here

Upvotes: 0

Views: 444

Answers (1)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93444

The "#" is called a fragment, and is considered "client dependent". In other words, it's for the client and does not get sent back to the server. So, the server doesn't know what the fragment might be to redirect to. See

http://en.wikipedia.org/wiki/Fragment_identifier

From the Wikipedia article:

Fragments depend on the document MIME type and are evaluated by the client (Web browser). Clients are not supposed to send URI-fragments to servers when they retrieve a document, and without help from a local application (see below) fragments do not participate in HTTP redirections.[

Upvotes: 1

Related Questions