0

我想在 url 中传递加密的电子邮件，但它不能在服务器上工作，而它在 localhost 上工作。

我检查了加密的电子邮件-它包含一些特定的字符，例如 + ，= 所有那些包含 + 符号的 url 在服务器上都不起作用。但它在本地主机上工作。

例如 - url 格式 - {controllername}/{methodname}/{encrypted email}/{bool}

工作网址 - www.test.com/home/index/IZoc1QJlukTro7XN4kTaRDoy7mPNS-14YjKeZsXeyt3XsL4tXbLUPQ==/false

不工作的网址 - www.test.com/home/index/KV6UWqy5fN7FY+lZuMAQ5nvA0+X4f8sQyB0la+-bSawUPEY1TIHK-C2bUdZUBRA6/false

不工作的 url 会给出类似 404 的错误 - 找不到文件或目录。您要查找的资源可能已被删除、名称已更改或暂时不可用。

想法？

4

1 回答 1

0

您应该将其作为 url 编码的查询字符串参数传递，而不是作为路由的一部分：

http://www.test.com/home/index?email=IZoc1QJlukTro7XN4kTaRDoy7mPNS-14YjKeZsXeyt3XsL4tXbLUPQ%3D%3D%2Ffalse

如果你想传递一些字符串作为路由的一部分，你应该确保它不包含危险字符，这是你的情况。Scott Hanselman 写了一篇精彩而详细的博客文章，介绍了如果您尝试在此处将此类字符串作为路由的一部分传递时可能遇到的困难：http ://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

如果您不想浏览整个帖子，我将引用他的结论：

在为在请求路径中获得疯狂的东西所做的所有努力之后，值得一提的是，简单地将值保留为查询字符串的一部分（还记得本文开头的 WAY 吗？）更容易、更清洁、更灵活，而且更多安全的。

于 2013-08-12T07:24:13.230 回答