Table of Contents
I created this plugin to remove the HTTP referer most browsers send.
Why should someone want to remove the HTTP referer? I'm running a private wiki, which shouldn't be accessed by unauthorized people. If someone clicks a link in my wiki, the URL would probably transferred to the destination site. With this plugin I try to avoid this.
- 2019-01-02: PHP7 compatibility (thanks Dwight Donovan Benvenuto)
- 2017-10-06: Fix external dereferer (thanks Doobry)
- 2015-09-10: Bug fixes (thanks Christoph).
- 2015-08-20: Code optimized.
- 2014-01-04: An option to ignore URLs pointing to the same domain where dokuwiki is running added. (enabled by default)
- 2013-11-12: Replaced PHP short open tag with
- 2013-05-12: Removed Java-Script, switched to HTML5.
- 2010-03-28: Support for interwiki links added.
In order to use this plugin, you have to change the
renderer_xhtml option in the configuration to
In the plugin configuration you can customize the string to add in front of an URL as you want. Default setting is to point to an included PHP script called
redirect.php, which redirects after 1 second to the destination. This way the HTTP referer should be removed.
If you want to use an external service such as anonym.to, you can enter something like:
So nobody complains anything, I guess everything works fine with this plugin :o)
- Doesnt work on the Docs links in the extension manager
I don't think so. I've added the plugin, but it doesn't seem to work. In the Sourcecode there is still no thing like “http://anonym.to?”. Im using Angua. Is there any reset to trigger? THX
Did you change the
renderer_xhtmloption in your configuration? Please read the complete instruction above.
— Heiko 2014/02/05 00:14
Thanks, worked. I thought the renderer_xhtml was the option provided by the plugin itself. Sorry, my bad.
Hi, I added this plugin and it almost worked right away. The only quirk is that I had to add '<?php' to the beginning of redirect.php, where it only started with '<?'. It refuses to render with only '<?' on my server.
Thanks for reporting. I'll fix that asap. — Heiko 2014-06-10 16:50
Wrongly affects other protocols
I enabled the file:// scheme according to urlschemes and configured firefox to allow local links from my dokuwiki instance. Unfortunately the linkprefixplugin gets in the way and changes the URI from e.g.
When I checked the other protocols I found they're affected, too.1)
I guess this is unintented behaviour and should probably be fixed.
Fixed. — Heiko 2015-09-10 03:00
If one uses more than one Interwiki link in a row only the first one will work.
[[doku>tips|Working]] [[doku>tips|Broken]] [[doku>tips|Broken]]
I'm (also previous bug report) using the 2014-09-29d “Hrun” release, but for the plugin this shouldnt matter, should it?
Fixed. — Heiko 2015-09-10 03:00
Seems like the plugin is broken with external dereferers. It always prefixes the URL with $_SERVER[“HTTP_HOST”] which doesn't make sense for external dereferers. Also, some external dereferers don't expect urlencoded URLs. Thus the following change was necessary (which in turn breaks the plugin for the internal dereferer):
- $url = $protocol . "://" . $_SERVER["HTTP_HOST"] . $this->getConf('prefix') . urlencode($url); + // Plugin was broken with external dereferer: + // * prefix of $_SERVER["HTTP_HOST"] doesn't make sense with + // an external dereferer + // * our dereferer doesn't like urlencoded URLs + //$url = $protocol . "://" . $_SERVER["HTTP_HOST"] . $this->getConf('prefix') . urlencode($url); + $url = $this->getConf('prefix') . $url;
You are right, $_SERVER[“HTTP_HOST”] makes absolutely no sense :) I will fix that and provide an option to disable URL encoding. — Heiko 2017-09-26 00:09