2

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.

Triynko
  • 18,766
  • 21
  • 107
  • 173
  • what login framework are you using? – Jesse Oct 24 '11 at 19:04
  • forms authentication, and the web.config "authorization" section is set to deny anonymous users and allow authenticated users at the root, which is inherited by subdirectories. Public subdirectories such as the login page itself and the content folder authorize all users (as well as anonymous), so the content can be accessed without being logged in. – Triynko Oct 24 '11 at 19:06
  • Use Authorize Attribute on Index action for your site `[Authorize] public ActionResult Index() { return View(); }` – Emmanuel N Oct 24 '11 at 19:07
  • **[Authorize]** public ActionResult Index(){return View();} does not help. Same behavior. Remember, I have set "authorization" in web.config to deny access to anonymous users by default, so the Authorize attribute (which causes authentication to be required) is redundant anyway. – Triynko Oct 24 '11 at 19:09

2 Answers2

2

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.

Community
  • 1
  • 1
Triynko
  • 18,766
  • 21
  • 107
  • 173
  • MVC 4 fixes the add to every controller problem. See http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx – RickAndMSFT Mar 23 '12 at 22:01
1

You should not have to modify your routing to get this to work correctly. For your "authentication" required actions ensure they are decorated with the [Authorize] attribute.

With forms authentication this will redirect users to the loginUrl specified in your config:

<system.web>
  <authentication mode="Forms">
    <forms loginUrl="Login.aspx" />
  </authentication>
</system.web>

After authentication occurs, information about the originating page will be placed in the query string using RETURNURL as the key.

Edit: Within the /myapp controller's action result check to see if the user is authenticated via Request.IsAuthenticated. If authenticated and the return url is "/myapp" (second check may not be necessary), redirect them over to the desired controller / action.

Edit2: The default controller / action is specified in your global.asax. For example:

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);

This should be where you are redirecting to with RedirectToRouteResult.

Jesse
  • 8,223
  • 6
  • 49
  • 81
  • I think you're misunderstanding the problem. Authentication is occurring. [Authorize] is in place where it needs to be. Additionally, the web.config has the "authorization" section set up to deny anonymous users access to all paths except public content and login-related pages. The problem is that when users visit the root of the site, the default behavior of the forms authentication module is to append a return URL of the root of the site, which is incorrect. I want it to redirect to the home page by default, not the site root, which by default goes to the login page. – Triynko Oct 24 '11 at 19:23
  • @Triynko yes, I did misunderstand. See Edit. – Jesse Oct 24 '11 at 19:33
  • If I change the RegisterRoutes method's first call to MapRoute to pass a "defaults" object with controller = "Home" and action = "Index", then after logging in it takes me to the home page, however none of my images show up, because the current URL in the browser is left at the root. I really need the redirectUrl to be something other than the root, or some solution that causes a proper redirect after logging in from visiting the root. – Triynko Oct 24 '11 at 19:33
  • Well, there is no controller for the root path. There are controllers for subpaths like "Home", "Account", etc. The AccountController/LogOn method has code that calls RedirectToAction("Index","Home") when returnUrl is blank. Otherwise it redirects to the returnUrl. Are you saying I need to hard code that section to check for the application's root path into my code? What if the root path changes? – Triynko Oct 24 '11 at 19:38
  • That may be your problem as you should always have a default route specified. For example if the page you are trying to route to is the home controller action index, then your route should reflect this. This is also the route you would redirect to upon authentication. – Jesse Oct 24 '11 at 19:46
  • The default MapRoute goes to Account/LogOn, not Home/Index, but that is correct, because when visiting the root, I want users to go to the log on page. The problem is that Account/LogOn is protected by the web.config's authorization section, so forms authentication generates a bogus URL with a redirect to itself. I cannot seem to add an exception for it though using a localized authorization section like: . Perhaps the path should be "Views/Account/LogOn"? – Triynko Oct 24 '11 at 20:04
  • That's your problem. Don't make the default route the login page. Make it the index page, and then decorate pages you required authorization for with the [Authorize] attribute. – Jesse Oct 24 '11 at 20:07
  • No, that's not the problem. If I make the default route the home page, then the browser URL is not updated correctly and none of the pictures show up on the home page after logging in, because the browser has an invalid current directory for relative paths. i.e. the browser url is still "mysite.com/myapp" after the redirect to the home page, so the relative URLS for the page are all invalid. The problem is the forms authentication module is adding a bogus redirect to itself, because the page is secured. – Triynko Oct 24 '11 at 20:10
  • The question, I would ask then is how are you referencing your images within your views? For example are you using Url.Content("~/Content/Edit.png") to let the framework put the relative path in for you? – Jesse Oct 24 '11 at 20:17
  • Are you saying you cannot use relative URLs in an MVC application, or in other words you must use the "~" app root relative indicator so that Url.Content can render a URL absolute to the host "/myapp/Content"? I guess if the framework is doing internal transfers and just rendering output in complete disreguard for the browser's current URL, then everything would have to be specified absolutely from the host. – Triynko Oct 24 '11 at 20:27
  • I think it's fixed now. I made all the links and images use Url.Content, and made all paths relative to the application root using "~" when passing them to Url.Content. The default route is now "Home/Index". Everything seems to be ok, but the real problem is that the initial visit to the site root has forms authentication adding a redirect to itself, because access to the login page is restricted and I cannot seem to add an exception. This prevents the log in controller from cleanly handling a redirect to home, and instead it redirects to the bogus returnUrl that should never be there. – Triynko Oct 24 '11 at 20:36
  • In fact, this is all stemming from an incompatibility between the MVC framework routing and security model using the [Authroize] attribute, verses the ASP.NET security model using and tags: see http://stackoverflow.com/questions/2550522/web-config-asp-net-mvc-location-system-web-authorization-integrated-se – Triynko Oct 24 '11 at 20:42
  • Thanks for your help Jesse! 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. – Triynko Oct 25 '11 at 14:36