如何屏蔽地址栏中的推荐 URL答案

【问题标题】：How to mask referral URLs in address bar如何屏蔽地址栏中的推荐 URL
【发布时间】：2012-12-27 16:54:37
【问题描述】：

假设我有一个推荐 URL http://www.example.com/r?ref=86745348，我想对访问者完全隐藏 URL 的 r?ref=86745348 部分。

我试过这种方法：

<?php
header("Location: http://www.example.com/r?ref=86745348");
exit;
?>

我已经尝试过像 TinyURL 这样的 url shortners。

我所有的尝试都隐藏了超链接中的 URL，但没有隐藏用户浏览器地址栏中的 URL。

无论我做什么，一旦用户登陆推荐页面，他们就可以看到推荐链接，将其删除，并欺骗我的推荐。

所以我的问题是，如何从地址栏中隐藏推荐链接？

【问题讨论】：

那么如何改变第三方对其 URL 的处理方式？祝你好运。
您可能会发现任何体面的基于推荐的网站都会在会话中保留推荐人 ID，这样用户是否将其从 URL 中删除也无所谓
Facebook 就是一个例子。推荐链接不保留在会话中，完全依赖于 GET 方法。
@Jonathan 你能澄清一下你说的 Facebook 推荐系统是什么吗？不是不相信你，只是对你所指的东西感兴趣（不是双关语）。
@Jonathan 这不是 Facebook 实施推荐计划，而是链接到的人。

标签： php html url hyperlink referrals

【解决方案1】：

你不能。

如果您的商业计划依赖于诱使用户没有意识到您正在收取推荐费，那么您需要退后一步并重新评估您在做什么。

【讨论】：

1) 不是企业。 2）重点不是欺骗人。关键是要阻止那些通过从 URL 中删除推荐 ID 来窃取我推荐的人。这是关于保留属于我的东西，而不是为别人做免费广告。
谁是“那些会窃取你推荐的人”？让我重申一下：如果您担心您所引用的其他服务的用户不希望被标记为您所引用的，那么您所做的事情很奇怪，而且可能是错误的。
最简单的例子是一个游戏，你可以通过推荐人来获得积分。推荐是由游戏通过 GET 方法发送的。用户可以在他的地址栏中删除这部分 url，重新加载页面然后“进入”，此时用户喜欢游戏，而我失去了奖励积分。这对用户有利，因为与推荐他的人相比，这给了他很大的优势。
这似乎是游戏中的一个重大设计缺陷。我见过的大多数有推荐计划（游戏和商业服务）的网站都会奖励推荐用户和推荐用户；惩罚被推荐的用户只是倒退。

【解决方案2】：

我同意@duskwuff。这是错误的......但只是为了知识范围。这将起作用。使用以下代码创建一个 HTML 页面并将用户发送到该页面。

<iframe src="http://www.example.com" width="100%" height="1024"></iframe>

想法：使用整页 iframe 在页面 B 中加载页面 A 以隐藏页面 A 的 url

【讨论】：

丑陋，但在技术上是可行的（尽管我不确定特定的 height 属性是个好主意）。请注意，第 3 方网站可能有代码来打破此类 iframe，和/或以这种方式显示时无法按预期运行。
另外，请注意，您假定的不诚实访问者只需要一点技术知识就可以发现他们以这种方式被圈养，并通过查看 HTML 源来发现页面的真实 URL。

【解决方案3】：

那么第一个问题必须是 - 究竟是谁在监控这些充当推荐人的参数？我认为解析 $_GET['ref'] 参数号的不是您的服务器和脚本？

也许如果服务器“计算”引用实际上使用 $_REQUEST 参数而不是普通的“可见”$_GET 参数，那么您也许可以使用 $_POST 因此“隐藏”参数用户。

快速搜索新的和改进的搜索 yeilded this helpful answer 处理带有 $_POST 数据的重定向。

【讨论】：

【解决方案4】：

您试图实现的逻辑只能在超链接的接收端实现 - 您不能欺骗浏览器访问一个 URL，而是告诉用户他们在另一个 URL，因为这将是一个巨大的安全风险。

如果您链接到的服务以合理的方式实施了引荐跟踪，那么一旦用户登陆他们的网站，就会植入一个 cookie，这样删除查询字符串不会影响引荐的跟踪方式.目标站点甚至可以自己整理 URL，将用户重定向到没有查询字符串的版本，但同样，这是只有他们才能实现的。

如果目标网站的实现方式是删除查询字符串就足以剥夺您的推荐费，那么是他们在抢劫您，而不是用户。

【讨论】：

我不相信第三方的糟糕编程会剥夺我的推荐，而我的推荐是用户自己故意删除的。这当然没有帮助，但 99% 的推荐似乎只使用 GET 方法而不是 POST。
@Jonathan 我没有提到 POST；大多数推荐将在用户到达后立即将其存储到 cookie 或会话中。否则，当客户选择产品或完成预订流程时，应用程序必须将推荐参数复制到每个内部链接和表单上。
我知道你没有提到 POST。我只是陈述我的观察，如果大多数网站可以避免它，他们不会使用 cookie 方法，因为许多用户一开始就不再接受 cookie。因此首选 GET/POST。
@Jonathan 很少有购物或游戏网站会在禁用 cookie 的情况下运行，因为这是它们保持正常状态的唯一方法，例如您的购物车内容或您的状态登录用户。（还有一种替代方法，即在每个内部 URL 中附加一个会话 ID，但它比“抱歉，您需要接受 cookie”的消息更难实现。）

【解决方案5】：

我们可以做到这一点的一种方法是使用浏览器历史记录设置。以下是在我的解决方案中帮助我的代码 sn-p

<script>
        $(document).ready(function () {
            //Masking the Url
            var loc = window.location;
            var pathName = loc.pathname.substring(0, loc.pathname.lastIndexOf('/') + 1);
            var absolutepath = loc.href.substring(0, loc.href.length - ((loc.pathname + loc.search + loc.hash).length - pathName.length));
            window.history.pushState("Object Or String", "Title", absolutepath);
        });
   </script>

【讨论】：

【解决方案6】：

只需将此代码复制并粘贴到您的 .htaccess 文件中即可：

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.php [NC,L]

很简单

【讨论】：