When I first visit my site using URL: http://mysite.com/myapp, I am redirected to the login page, but the returnUrl is “/myapp”.
How do I ensure that upon first visit, it redirects to the login page, but the return URL is something other than the login page itself, such as “~/Home/Index”.
I have tried adding a routes.MapRoute, passing an empty string to the “url” parameter, and in the object passed to “defaults” I include a value for the returnUrl member as “~/Home/Index”, but that’s not affecting anything.
I’ve tried creating a default document, and ensuring full anonymous access to it an the login page, but that’s not working either… it always redirects and appends a returnUrl of the login page itself, which is dumb. This seems to be a problem with the default behavior of the routing system when property security is in place.
I figured it out.
The default IIS security mechanism for securing pages (i.e. the system.web/authorization section) is useless when using MVC, because with MVC you’re not securing actual physical pages or paths, but rather controllers and actions referenced through virtual paths called “routes”.
Instead of being able to secure everything with one line in web.config, you have to remember to add an [Authorize] attribute to every action you want secured (or to each controller class on which you want all actions secured), because everything is accessible by default. This means your security is code-based in MVC, rather than web.config-based, so you cannot change the settings without recompiling.
The exact problem here was that I was securing the app root directory with the authorization section, and was unable to add exceptions for physical sub-paths… because there really are none in MVC.. it’s all handled by the routing module. Therefore, when visiting the root with no exceptions possible, the forms authentication module was kicking in saying “no, you cannot access the root path” and was immediately serving the login page and adding a redirect back to the secured root.
Normally, having the default route go to Account/LogOn, would be fine, because Account/LogOn has code to redirect to Home/Index in the absense of a returnUrl. However, in this case, the authorization section was causing a returnUrl to be generated by forms authentication, which sabataged the ability of the Account/LogOn action to perform a default redirect. Changing the default route to Home/Index fixed that problem; however this left the browser’s URL incorrect, and that’s when I ran into the problem of URL’s being specified as “../Content/image.jpg”, rather than @Url.Content(“~/Content/image.jpg”).
So as you can see, this was a complex, multifaceted problem here that arose from a clash of architectures.
See: Problem with Authorization with IIS and MVC
and
See: How do I allow all users access to one route within a website with integrated auth?
To summarize, good suggestions were 1: default route should go to home rather than login, 2: ensure you let the framework generate content URLs relative to application root, 3: add to the http-get action of the login page a redirect to home if Request.IsAuthenticated is true, and 4: use [Authorize] attribute to secure action methods.