Как скрыть файл в ссылке

Обновлено: 07.07.2024

Часто слышу, что сеошники советуют убирать окончания .html, .php и .htm в адресах ваших сайтов – якобы, это негативно влияет на продвижение. Кто-то же говорит, что это просто визуально добавляет адресу лишний мусор.

В любом случае, убирать или оставлять эти окончания, решать вам, я же покажу, как это реализовать на статичном сайте (то есть сайте, находящемся не на CMS). Почему только на статичном? Потому что для различных CMS это реализовывается разными методами, о которых я также расскажу в последующих статьях.

Не утверждаю на 100%, что этот метод не будет работать на какой-то из CMS – пробуйте и о результатах отписывайтесь в комментариях.

Убираем .html, .php и .htm на Apache

Как вы знаете, в Apache существует файл .htaccess, который содержит в себе набор настроек и конфигураций сервера. С его помощью мы и будем убирать ненужные нам окончания.

1. Подключитесь к сайту по FTP и в корне сайта найдите файл .htaccess. Откройте его. Если такой файл отсутствует – создайте.

2. Найдите строчку, содержащую:

Сразу после нее вставьте следующие правила.

Если вам необходимо убрать .php:

Если вам необходимо убрать .html:

Если вам необходимо убрать .htm:

Если строчка «RewriteEngine On» отсутствует в файле – добавьте ее в самое начало.

После чего сохраните изменения и отправьте файл обратно на сайт. Если раньше адреса на вашем сайте были вида

то теперь вы можете открыть эту страницу по адресу:

Убираем .html, .php и .htm на Nginx

1. Для того чтобы подобную настройку произвести в Nginx, откройте файл конфигурации по адресу:

в FTP (если вам позволяют права) либо через панель управления сервером.

2. Далее, в секцию location / , вставляем необходимые правила.

Если вам необходимо убрать .php:

Если вам необходимо убрать .html:

Если вам необходимо убрать .htm:

Если в процессе настройки у вас что-то не получается – пишите об этом в комментариях.

Здравствуйте.
Вы можете сменить каталог хранения файлов и скрыть реальные пути используя mod_rewrite для преобразования ссылок. Это даст возможность выполнять обращение по реальным адресам, не видимым никому. Вариантом может быть также написание программистами (либо использование уже готового решения для вашей CMS) дополнительного модуля для защиты.

Я сам в этом не разбираюсь, может ли кто-нибудь разложить все по полочкам?

Вариантов это сделать - 2.

1) Если у Вас файлы маленькие - можно просто читать их из php скрипта и отдавать.
Перед этим можно проверять имеет ли право текущий пользователь скачивать этот файл.
Что то вроде

Плюс то что не требуется никакой дополнительной настройки, не зависит от ПО сервера, минус то что это решение жрет память т.к файл целиком грузится в php, жрет время бекенда т.к php скрипт работает пока не закончится загрузка.
В целом это решение я использовать не рекомендую.

2) Использовать nginx и директиву X-Accel-Redirect.
В конфиге nginx

В php коде соответственно

Решение отличное, быстрое.

Сделайте авторизацию для Ваших клиентов и далее проверяйте является ли он пользователем.
Какая у Вас CMS?

Все гораздо проще. Делаете магазин файлов на готовой CMS. В данном случае подойдет Moguta CMS в бесплатной ипостаси. А после подключаете возможность покупки по кодовому слову. Торгуете собственно именно этими кодовыми словами.
Торговать ссылками. а кто помешает скаченное разместить на яндексдиске/ином ресурсе?
А после этого можно сколько угодно распространять ссыль. Даже с торрентом не придется заморачиваться.

Лучший вариант - это шифровка самого файла, а доступ по паролю, который будет автоматом высылаться на почту, которую введет покупатель. Хотя это другая проблема и другой вопрос :)

А вообще, писать такой вопрос не указав нормального ТЗ и не указав предпочитаемую CMS бесмыссленно.

Но теперь у меня загвоздка - url ссылки нужно максимально скрыть от покупателя, чтобы его мог знать только продавец и администратор, но чтобы при этом файл можно было скачать. Нужно это что бы ссылка не передавалась из рук в руки. Поиск в основном выдает кучу информации про редирект, который делают дабы закрыть ссылку от поисковых роботов, но это наверное не совсем то что нужно.. хотя с помощью редиректа я немного приблизился к решению задачи..

Попробовал, установил модуль redirect и с помощью вот этого мануала настроил его так, что при обновлении или создании нод, для ссылки из поля field_link автоматически создается редирект. К примеру для ссылки "http://files1.freesoft.ru/rep/2014/7z920-x64.msi" автоматически создается редирект вида "drupal/node/download/38". Ну и соответственно во вьюхах у меня выводится ссылка с нужным паттерном. При клике на замаскированную ссылку (если ссылка прямая) никуда не перебрасывает и сразу же начинается скачивание файла.

В общем прошу совета, может быть я изобретаю велосипед и кто-то уже что-то подобное реализовывал. Основной вопрос конечно - Как полностью скрыть URL на внешний файл от пользователей? И может быть редирект тут вовсе и не при чём.

Имхо, лучше заморочиться с файлом, а не с модулями.
Продавцы большие файлы продают?В мегабайтах всмысле.
Если мелкие - после покупки можешь скидывать их себе, отдавать покупателю,а потом удалять.
Я когда то давно делал нечто подобное, я вроде-бы делал редирект на самого себя, насколько я помню.

между ними демагогия из друпальских модулей и редиректов
Ну это чтобы понятна была суть задачи.. Потому что обычно цель скрытия урлов - защита от поисковых роботов, при котором увидеть урл для человека не составляет проблем.

Размер файлов может быть от нескольких килобайт до нескольких гигабайт, думаю в основном в размер dvd диска, поэтому я и не хочу хранить файлы на сервере, тем более по началу. У меня денег не хватит на такой серв

В общем, отпишусь о своих успехах.
Теперь у меня при нажатии на ссылку пользователи фильтруются по признаку купил продукт или нет, те кто не купил - идут лесом, для тех кто купил - срабатывает скрипт, который парсит внешний файл и выдает его пользователю. URL ссылки не видно абсолютно нигде, кроме как на странице редактирования материала(!). Менеджер загрузок говорит, что файл скачан с "node/download/38"(!).

if( preg_match( "/^HTTP\/1\.[01] (\d\d\d)/", $data, $matches ) ) $status = (int)$matches[1];
>

if( preg_match( "/Content-Length: (\d+)/", $data, $matches ) ) $content_length = (int)$matches[1];
>

Итак, мне удалось подружить nginx со своим виртуальным хостингом и я разобрался, как перевесить проксирование файлов на nginx. Теперь самое главное чтобы то же самое можно было проделать у реального хостера.

Ссылок с моей надстройкой не видно абсолютно нигде, сервер не нагружается, отдача файлов моментальная, скачивание идет в несколько потоков (по умолчанию 768 соединений и можно увеличить).
В общем удобно и красиво. Есть только маленький недочет, о нем после.

Обе моих функции в template.php теперь превратились в довольно миниатюрный код:
<?php
function file_download_url($url) if ($url) header('X-Accel-Redirect: /internal_redirect/'.$url.'filenameis:'.basename($url));
exit; //может exit тут лишний, остался от предыдущего варианта
>
>
?>

Что тут происходит. Функция отправляет заголовок "X-Accel-Redirect", чем сообщает nginx'у, что надо бы что-то сделать со ссылкой. Полностью ссылка в моем примере выглядит как-то так: "/internal_redirect/http://files1.freesoft.ru/rep/2014/7z920-x64.msifilenameis:7z920-x64.msi"

nginx.conf сконфигурирован у меня следующим образом (инфа в комментах):
<?php
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events worker_connections 768;
>

include /etc/nginx/mime.types;
default_type application/octet-stream;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

gzip on;
gzip_disable "msie6";

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

* /internal_redirect/(.*)filenameis:(.*) < //В основном нас волнует именно эта секция, от этой строки, до ">". Эта строка задаёт regex
//regex - это паттерн, который реагирует на мою ссылку, которую я сформировал в функции
//в этом регэксе говорится - среагировать на ссылку, начинающуюся на "/internal_redirect/",
//вычленить в первую переменную весь следующий код, до "filenameis:", то что после "filenameis:"
//засунуть во вторую переменную. Если в ссылке не будет "/internal_redirect/", символов, "filenameis:",
//символов, до данная секция не сработает. Проверить свой паттерн можно с помощью онлайн сервиса
//"http://regex.tacticalvim.com/photobooks/index.html"

//кстати такие комментарии, как этот, conf воспримет как код, так что не забудьте стереть

internal; //работает и с этой строкой и без нее
resolver 8.8.8.8; //эта строка отправляет адрес на иденификацию гугловскому прокси, чтобы понять на какой адрес стучаться
//без resolver валится, кажется ошибка 502

access_log logs/internal_redirect.access.log; //куда писать логи доступа
error_log logs/internal_redirect.error.log; //куда писать логи ошибок

set $name $2; //засовываем в переменную $name, все что во вторых скобках regex'а
set $url $1; //засовываем в переменную $url, все что в первых скобках regex'а
//можно просто использовать переменные $1 и $2

proxy_set_header Authorization ''; //без этой строки лезут ошибки
proxy_hide_header Content-Disposition; //убирал строку, ниче не происходило, но она у всех, так что оставил
add_header Content-Disposition 'attachment; filename="$name"'; //че-то у меня все слезло, так что строкой ниже..
//в этой строке добавляется заголовок, который говорит nginx'у, что файл надо бы скачать,
//а не открывать, и скачать его нужно под именем $name, которое берется из вторых скобок
//regex'а.. В php функции это имя задает "basename($url);", и в данном примере
//выглядит как "7z920-x64.msi"

proxy_max_temp_file_size 0; //не проверял, но по идее говорит, что файл скачивать не надо никуда, надо его
//сразу отдать клиенту.. и на самом деле так и происходит

proxy_pass $url; //проксируем файл пользователю
> //ну и все, не так уж и много тут кода

//хочу предупредить, если ссылка оканчивается на любой из форматов, прописанных
//в следующем location, то данная локаль должна стоять выше следующей, если же она
//будет стоять ниже следующей локали, то сработает regex из следующей локали.
//короче, если следующая локаль будет выше нашей локали, и ссыль будет заканчиваться на .jpg
//то наша локаль не сработает и полезут ошибки в логах.. так вроде понятней

В этой статье мы поговорим об актуальной для многих вебмастеров проблеме - спрятать урлы ваших партнерских программ. Я надеюсь, что вы уже не относитесь к новичкам, которые создают сайты для размещения фотографий любимого кота или как я круто провел лето в деревне на бесплатных хостах типа народа. У нас дела посерьезнее - на своих веб-сайтах заработать, да и желательно не только на хостинг и доменное имя, но и на пиво, мобилу, компьютер.

К написанию этой статьи меня побудило то, что большинство вебмастеров зарабатывают на своих сайтах, участвуя в различных партнерских программах. Только не путать с контекстной рекламой - это из другой оперы - у них все линки, по которым будут переходить пользователи (а нам с вами поступать денежки), генерируются с помощью java-скрипта, так что вмешиваться в процесс их генерации мы не можем (да и не разрешено это).

Итак, допустим вы зарегистрировались в некой партнерской программе по продаже, к примеру, книжек. Вам, как партнеру дается свой уникальный урл. Если посетитель по нему перейдет с вашего сайта на сайт продавца и купит что-то, то вам будет % от продажи (комиссионные).

А теперь переходим к практике

Прячем URL с помощью javascript

Чтобы замаскировать линк http://www.sape.ru/r.ewPYUJTHdw.php на "полезная ссылка для каждого вебмастера".

Делаем следующий линк:

Другой вариант:
Преимущества - не требуется наличие php на хостинге

Недостатки - это лишь защита от новичков, ведь сам линк с редиректом сохраняется внутри html-кода.

Прячем с помощью PHP

Для этого нужно использовать технологию server side scripting - скрипты на стороне сервера - т.е. закачиваете скрипт на сервер, он его обрабатывает, а в браузер выдает результат этой обработки. Единственное условие - это поддержка хостером PHP.

Все предельно просто - создаем в корневой директории (если в другом месте, укажите путь) файл coolbook.php с таким кодом:

Далее осталось только загрузить его на сервер. В html коде делаем переход по реферальской ссылке вот так:
Преимущества - посетители и AdWare не смогут увидеть, что же скрывается в настоящей ссылке (наш реферальный код). Все надежно запрятано в php файле и хранится на сервере хостера.

Недостатки - для каждой партнерской ссылки нужен свой отдельный файл. Хорошо, если у вас одна такая программа, а если несколько? Для этого рассмотрим решение третье:

Прячем линки с помощью средствами сервера apache и файла .htaccess

Ясно дело, что такая техника не будет работать на бесплатном хосте без поддержки php. Также убедитесь, что ваш хостер (а точнее его apache настроен) поддерживает работу с файлами .htaccess. Есть и такие, у которых он отключен видите ли для безопасности :)

Так вот, в корневой директории вашего хоста (как правило, папка типа public_html или www), создаем файл .htaccess (именно такой, если делать его в блокноте, то будет еще приставка txt - внимательно с этим). Заливаем на хост с помощью любого FTP клиента (советую FlashFXP).

В html-коде используется так:

Преимущества - хранит все линки в одном файле. Не нужно создавать для отдельной партнерской программы отдельный файла

Недостатки - нужно разбираться в синтаксисе файла .htaccess. Опять же, некоторые хостеры не дают возможности изменять этот файл (только для чтения). Ну и нужно быть предельно внимательным с директивами .htaccess - а то можно завалить не то, что свою cms, а и весь хост :)