如何在ASP.Net MVC 3中接受电子邮件参数

Sea*_*ron 1 asp.net-mvc-3

我正在使用ASP.Net MVC 3,并尝试将电子邮件地址作为参数传递到URL中,如下所示:

www.myapp.co.uk/customers/changedetails/john@doe.com

传入时参数值为null.如果我使用参数则工作;

www.myapp.co.uk/customers/changedetails/?email=john@doe.com

我的控制器看起来像这样:

    public class CustomerController {

    [HttpGet]
    public ViewResult ChangeDetails(string email)
    {
      var model = GetModel(email);
       return View(model);
    }
    }
Run Code Online (Sandbox Code Playgroud)

我的注册路线如下:

   public static void RegisterRoutes(RouteCollection routes)
   {
      routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
      routes.MapRoute(
          "Default",
          "{controller}/{action}/{id}",
          new { controller = "Home", action = "Index", id = UrlParameter.Optional }
      );
   }
Run Code Online (Sandbox Code Playgroud)

我错过了能够使用该电子邮件作为{id}参数(www.myapp.co.uk/customers/changedetails/john@doe.com)?:

Jan*_*nen 7

没有电子邮件作为最后的路线参数.或者如果你这样做,添加一个尾部斜杠.

/my/route/ee@mail.com -> fail
/my/route/ee@mail.com/ -> success
/my/ee@mail.com/route -> success
Run Code Online (Sandbox Code Playgroud)

这背后的推理是相当复杂的,但这里有一篇关于这些事情的好文章http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

我可以肯定的是,很多时候如果你有最后的电子邮件没有尾随斜线,请求甚至不会到达asp.net管道.它看起来像一个文件请求.话虽如此,它的*.com扩展看起来确实非常危险.在文件名中包含@当然不会降低它的可疑性.

你可能会让它运作起来.您可能需要放松安全性才能这样做,但它几乎肯定会在某些时候中断.

因此,最好的选择是将其保留为查询字符串参数.用斜线跟踪它的第二个最佳选择.