简体   繁体   English

损坏的查询字符串:“ 80”被IIS删除了吗?

[英]Corrupt Query String: “80” being removed by IIS?

I've been fighting this problem for a few days now, and can't seem to figure out what is causing it. 我已经为这个问题解决了几天,似乎无法弄清楚是什么原因造成的。

I have a registration system that requires activation. 我有一个需要激活的注册系统。 An email is sent to the user with a hash that is passed back to the server when they click the activation link. 当用户单击激活链接时,会将带有哈希值的电子邮件发送给用户,该哈希值将被传递回服务器。 Pretty basic stuff. 很基本的东西。 The link looks something like this: 链接看起来像这样:

http://site/activate.aspx?activationKey=26a51d9eba86c73b8f7e800c41bf55453ed3b1c4

While developing on my local machine (running VS2010), this works flawlessly. 在我的本地计算机(运行VS2010)上进行开发时,这可以完美工作。 However, when the site is pushed to the live server (IIS 6), the query string is being mangled, presumably by IIS. 但是,将站点推送到实时服务器(IIS 6)时,查询字符串可能被IIS破坏了。 Once the query string hits the code-behind, any occurrence of "80" has been stripped away, causing the activation to fail. 一旦查询字符串命中了后面的代码,任何出现的“ 80”都将被删除,从而导致激活失败。

I've wondered whether this is an encoding/decoding problem, but none of the characters are special, so I don't think that should be the case. 我想知道这是否是编码/解码问题,但是所有字符都不是特殊字符,因此我认为情况并非如此。

I know for a fact that IIS does not remove 80 from the querystring by default. 我知道,IIS默认情况下不会从查询字符串中删除80。 I have had it in querystrings many times on my sites without any problems. 我在我的网站上多次在查询字符串中使用它,没有任何问题。

Look through the IIS for url-rewrite rules. 在IIS中查找url重写规则。 I'm not sure if the IIS-log will use the final url or the url before IIS. 我不确定IIS日志是使用最终URL还是使用IIS之前的URL。 But considering it's 80 I guess someone want to remove port 80 from urls but has added a faulty rewrite rule for this. 但是考虑到它是80,我想有人想从URL中删除端口80,但是为此添加了错误的重写规则。

So I would look for a place where someone could have tried to strip port 80 from urls. 因此,我要寻找一个地方,有人可能试图从网址中剥离端口80。 Could be in IIS or upstream. 可以在IIS或上游。

turn on trace.axd on the website and check what the values are being sent across. 打开网站上的trace.axd并检查正在发送的值。 Are you sure that the email client is not doing anything 您确定电子邮件客户端未执行任何操作

Well, I found the problem. 好吧,我发现了问题。 @pst and @Mikael Eliasson were right, some goon did have some some rewrite rules in place, in a sense. @pst和@Mikael Eliasson是正确的,从某种意义上说,某些goon确实有一些重写规则。

The site is forced into SSL by redirecting a 403;4 error to another (pre-existing) app that rewrites the URL to use HTTPS. 通过将403; 4错误重定向到另一个(现有的)应用程序,该应用程序将URL重写为使用HTTPS,从而迫使该网站进入SSL。 In a sense, you can force SSL on an app, and the rest is (broken) magic. 从某种意义上说,您可以在应用程序上强制使用SSL,而其余的则是(无效的)魔术。 Here's the original code: 这是原始代码:

if ( Request.ServerVariables[ "SERVER_PORT" ] == "80" ) {
    try {
        string queryString, secureURL;

        queryString = Request.Url.AbsoluteUri.ToString();
        queryString = Request.ServerVariables[ "QUERY_STRING" ];
        Response.Write( queryString + "<br>" );

        secureURL = queryString.Replace( "http", "https" );
        secureURL = secureURL.Replace( "403;", "" );
        secureURL = secureURL.Replace( "80", "" );

        Response.Write( secureURL );
        Response.Redirect( secureURL );
    }
    catch ( Exception ex ) {
    }
}

Note the brutal replacement of "80" in there. 请注意在那里残酷地替换“ 80”。 Changing that replacement to ":80" fixes the problem, assuming I don't pass a query string with ":80" in it, which I won't. 假设我没有传递其中带有“:80”的查询字符串,则将该替换更改为“:80”可解决此问题。

Thanks for at least pointing me in the right direction, guys. 伙计们,至少感谢您为我指明了正确的方向。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM