Working with ASP.NET MVC3, site is in beta and customer decided to rename one of the controllers.
http://domain.com/foo[/*] -> http://domain.com/bar[/*]
What is the most straightforward way to handle redirecting so I don't break any foo bookmarks?
Keep the old controller around so the old URLs still work.
Or add a rewrite rule. Something like:
domain.com/foo(/[_0-9a-z-]+)
to:
domain.com/bar{R:1}
URL Rewrite in IIS
http://technet.microsoft.com/en-us/library/ee215194(WS.10).aspx
http://www.iis.net/download/URLRewrite
If you are using MVC.NET you probably already have URL Rewrite installed.
Another option would be to register a specific route for the old controller name in the Global.asax.cs.
routes.MapRoute(
"RenamedController", // Route name
"[OldControllerName]/{action}/{id}", // URL with parameters
new { controller = "[NewControllerName]", action = "Index", id = "" } // Parameter defaults
);
Add that before the standard default route, and your new controller should respond to both old and new names.
A 302 redirect would be fine, if you can figure out how to do that in IIS. This screenshot suggests it's not that arduous. Alternately, if you're using Castle Windsor you may want to register an interceptor that uses HttpResponse.Redirect()
REST standard suggests the best way to handle this issue is by returning a 301(Moved permanently request). Stack Overflow Post REST Standard
In .Net I recommend using Controller.RedirectToActionPermanent in your controller. See: ASP.NET, .NET Core
Code Example(should work for both ASP and Core):
public class MyController : ControllerBase
{
public IActionResult MyEndpoint(string routeValues1, string routeValues2)
{
return RedirectToActionPermanent("action", "controller", new { value1 = routeValues1, value2 = routeValues2 });
}
}
using MapRoute doesn't make sense in this case. MapRoute is really meant to provide a custom routing solution throughout the system. Its not really meant to deal with individual Redirects. As far as I'm aware it doesn't actually inform the user they are being redirected. See: Creating Custom Routes (C#)
Related
I recently rebuilt our webforms site as a hybrid mvc3/webforms website, with the newer code being replace with mvc. In the past, there was some code in the Application_Error method of the global asax file redirecting users to a 404
LifespeakExceptions.Log404();
HttpContext.Current.Server.Transfer("~/404.aspx");
However, when I tried to replace this with a route, it couldn't seem to find it - for example I tried this in the registermvc3routes file
routes.MapRoute(
"404", // Route name
"pagenotfound",
new { controller = "Utilities", action = "Error404Page" }
);
and I added this in global asax
LifespeakExceptions.Log404();
Response.RedirectToRoute("404");
However, it can't seem to find this route, even though I know it exists -- calling it directly correctly works. Could this be because it's a hybrid site?
Are there any possible security issues or pitfalls to, within a custom AuthorizeAttibute (registered globally), apply authorization based on the controller type and action being called?
e.g. (not real code)
string controllerFullName=_filterContext.ActionDescriptor.ControllerDescriptor.ControllerType.FullName;
string minRequiredRole = GetControllerMinRequiredRole(controllerFullName);
if(User.MeetsRoleRequirement(minRequiredRole))
{
//give access
}
else
{
//no you're not allowed
}
The main issue is with Authorization caching - so there are a few things to know. Check out the links I've posted here:
Creating a AuthorizeAttribute - what do I need to know?
Look at the code to the existing attribute and how it handles caching to ensure you arent causing the same issue the base attribute prevents.
MVC has great tools for building urls inside an MVC app by using routing. Routing by controller and action lets us avoid hard coding urls in markup.
But we have a bunch of ancillary services that need to create urls for marketing emails.
For instance, our email marketing campaigns may need to build a url for an offer. The MVC app knows how to build the url to the offer detail, but is there a clever way of doing this for the service app? Can we/should we move routing into a separate dll and reference it from one place?
Success stories/horror stories are appreciated.
it sounds like you should be using a catchall url to lookup actions you can manage in a DB such as:
Route like this
routes.MapRoute(
"MailCampaigns",
"/mailcampaigns/{*url}",
new {controller = "MailCampaigns", action = "Incoming" }
);
public ActionResult Incoming(string url)
{
//parse the url and perform actions accordingly
var actionInfo = repository.Query<ActionInfo>().Where(x => x.Url == url).SingleOrDefault();
return Redirect(actionInfo.TargetUrl);
}
I'm using ASP.NET MVC 3 (Razor) and have created a Controller named "Controllers" - specifically, the Controller class name is "ControllersController".
Here's a snippet of my "Controllers" Controller:
public class ControllersController : Controller
{
public ActionResult Index()
{
return View();
}
}
In addition to creating the ControllersController class, I created a Razor View (Index.cshtml) that correlates with the ControllersController Index() action. It may be worth noting that I created the Index.cshtml View by right-clicking the Index() method within the Controller and choosing "Add View".
The problem that I am experiencing is, when a browser tries to go to http://localhost/controllers, the following error is thrown:
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource
you are looking for (or one of its
dependencies) could have been removed,
had its name changed, or is
temporarily unavailable. Please
review the following URL and make sure
that it is spelled correctly.
Requested URL: /controllers/
There are two points that I'd like to point out:
The error can be avoided if the
browser explicitly goes to
http://localhost/controllers/index
Controllers that are not named
ControllersController don't force
the browser to specify the /index
action in its URL.
With all the naming conventions in MVC, I'm not surprised that a Controller named Controllers causes some strange behavior. My question is; what do I need to do so that I don't have to specify /index in the browser's URL?
This is because you have a folder called "Controllers" on disk in your project. One option would be to rename that folder to something else. This problem won't exist when you publish your site using the Visual Studio publish option because the Controllers folder won't get pushed. A second more cumbersome solution would be to set routes.RouteExistingFiles = true; in the RegisterRoutes function in your global.asax.cs. You then may want to call route.IgnoreRoutes for items in your content folder, etc.
Stay away from using any current names in your code - the world will be a better place, children wont cry, etc.
"With all the naming conventions in MVC, I'm not surprised that a Controller named Controllers causes some strange behavior. "
If it feels weird - don't do it : )
Apparently, the problem has nothing to do with the name of the Controller (i.e. ControllersController), but rather with the name of the URL route.
In my Global.asax.cs, I added a custom route as follows:
public static void RegisterRoutes(RouteCollection routes)
{
//Route /controllers/ to /Home/Index
routes.MapRoute(
"Controllers",
"controllers/{action}/{id}",
new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);
}
Notice the the custom route (named "Controllers") routes to the HomeController (not ControllersController).
I would expect that when the browser points to http://localhost/controllers, MVC would return the /Home/Index page. Instead, a 404 error is thrown. However, the route succeeds if the browser points to http://localhost/controllers/index. - This is the same symptoms as I mentioned at the beginning of this post.
Based on this test, I think it's safe to assume that the problem is not with the naming convention of the Controller, but rather with the naming convention of the MVC routing.
To move on with building my application, I'm going to change the name of my ControllersController to ControllerSystemsController. In the meantime, I'm interested to know specifically why the MVC router doesn't work as expected for routes that use "controllers" as the name of the controller. Can anyone shed light on this?
I'm still trying to figure things out with StructureMap and one of the issues i'm running into is my Controller Factory class blowing up when a null controller type is passed to it. This only happens when the application builds for the first time, after which every subsequent build works fine. Even when i shutdown Visual Studio and reopen the project (I'm not running this in IIS). It's almost like there is some sort of caching going on. This is what the controller class looks like:
public class IocControllerFactory : DefaultControllerFactory
{
protected override IController GetControllerInstance(Type controllerType)
{
try
{
return (Controller)ObjectFactory.GetInstance(controllerType);
}
catch (StructureMapException)
{
System.Diagnostics.Debug.WriteLine(ObjectFactory.WhatDoIHave());
throw;
}
}
}
What could be wrong? Do i need to have every controller registered? Thank you.
Most browser are looking for a favicon.ico when you load a site, and there is probably some caching involved with this behavior, this might explain the odd "Only fail on the first build" thing you mentionned.
In my case this was causing the problem of the null controller type in the controller factory.
Adding a routes.IgnoreRoute("{*favicon}", new { favicon = #"(.*/)?favicon.ico(/.*)?" }); in global.asax makes the error go away, the request should fall through to the filesystem without MVC looking for a favico.ico controller in your code.
Here is a link to Gunnar Peipman post about this
I found out by overriding GetControllerType(string controllerName) in my custom controller factory class and checking what the controllerName value was for each request.
I ran into the same problem with a controller factory built around ninject.
It seems MVC will pass you null for controllertype when it can't resolve a route from the routing table or when a route specifies a none existing controller. I did two things to solve this. You might want to check your route table and add a catchall route that shows a 404 error page like described here .Net MVC Routing Catchall not working
You could also check with the routing debugger what goes wrong.
http://haacked.com/archive/2008/03/13/url-routing-debugger.aspx
I was having the similar problem. I believe it was HTTP requests for nonexistent images, CSS files, etc.
We know the MVC routing first looks to see if the requested file physically exists. If it doesn't then the URL gets tested against the configured Routes. I think the request for an image that didn't physically exist was passed to the Routing engine, and didn't match any routes, so NULL was used.
So to fix it, use FireBug or something to watch for, and fix, broken HTTP requests. During development, I used a route like this to temporarily bypass these issues (all of my resource folders start with an underscore like _Images, _Styles, etc):
routes.IgnoreRoute("_*"); // TODO: Remove before launch
Hope this helps!
What I think you need to do is exactly the same thing that the default MVC controller factory does on the GetControllerInstance method. If you look at the Microsoft source code for DefaultControllerFactory at http://aspnetwebstack.codeplex.com/ you will see that the DefaultControllerFactory throws a 404 Exception when controllerType is null. Here is how we do it based on this information:
public class StructureMapControllerFactory : DefaultControllerFactory
{
protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
{
if (controllerType == null)
return base.GetControllerInstance(requestContext, controllerType);
var controller = ObjectFactory.GetInstance(controllerType);
return (IController)controller;
}
}
Basically this will ensure that, when user enters an invalid route the application handles it as a 404 error.