Научный консалтинг
Главная
Контакты
Номер телефона
Как мы работаем
Гарантии
Условия
Цены

Последнее обновление:

Анонимайзеры-онлайн и ссылки на вебстраницах

В этой статье мы поговорим об анонимайзерах-онлайн. Точнее, не о них самих, а о том, как они преобразуют ссылки в открываемых вебстраницах.

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

В конце статьи приведены некоторые рекомендации, которых целесообразно придерживаться разработчикам сайтов с тем, чтобы обеспечить возможность просмотра вебстраниц как можно большим количеством пользователей.

Как известно, анонимайзер-онлайн – это сайт (сервис), используя который, пользователь может «сменить» свой IP-адрес, заходя при этом на другие сайты. Обычно это делается путем ввода доменного имени сайта в специальной строке анонимайзера-онлайн и нажатия соответствующей кнопки. После чего сервис:

  1. САМ открывает (скачивает) с требующегося сайта необходимую вебстраницу
  2. Преобразует в ней все адреса ссылок на какие-то иные (не являющиеся «обычными» адресами)
  3. Передает преобразованную страницу пользователю, например, в его браузер

Иными словами, анонимайзер-онлайн выступает в роли сервера-посредника (прокси-сервера) между пользователем и требующимся сайтом.

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

Поговаривают, что, вроде бы, использование анонимайзеров кем-то запрещено (ну, пока срок президентства не окончился, по крайней мере). Вместе с тем, мы в этой статье вовсе не уговариваем читателя использовать анонимайзеры – во-первых. Не приводим списков анонимайзеров – во-вторых (тем более, что любой желающий сможет их найти). В-третьих, в любом случае, знать технологию работы – это одно. А вот пользоваться – это другое. Для нас, программистов, актуально знать и понимать принципы и особенности функционирования компьютерных систем. Ну, а у тех, кого обсуждают на «запрещенных» сайтах, дела – иные. Посему – не будем о том.

Иной раз, действительно, и мелькнет сообщение, что, мол, доступ к такому-то сайту зачем-то заблокирован провайдером.

Для чего анонимайзер подменяет ссылки на странице сайта? Причина одна – чтобы провайдер (в частности) не распознал (путем автоматического анализа содержимого страницы), что страница, которую скачал с сайта анонимайзер и которую передает в браузер пользователя, не несет в себе ничего «запрещенного». В качестве «запрещенного» могут фигурировать, в частности, ссылки, которые содержатся на «запрещенном» сайте, содержащие его доменное имя (к примеру, site.ru).

Допустим, страница site.ru/page.html может содержать ссылку типа site.ru/another_page.html. Тогда, при анализе провайдером ее содержимого – этот момент станет известен и такая страница будет заблокирована. Попутно (видимо, на всякий случай) анонимайзер подменяет и все остальные ссылки на открываемой странице – аналогичным образом.

Т.е. вместо

<a href="site.html/page.html">Ссылка</a>

на странице, переданной анонимайзером в браузер, может фигурировать что-то вроде

<a href="https://fsb**.com/pr**.php?u=eJw**LYD5DYqisWtkxB%2B8wF9toT4WlsPLIE77OPyJ09acpvIdjT7MM67oXiI7WD0xD">Ссылка</a>

Видно, что доменное имя заменилось на имя анонимайзера (прокси-сервера). А вместо page.html фигурирует некий хэш. На сервере анонимайзера, соответственно, есть таблица (база данных), в которой указано, что именно этому хэшу (или его части) соответствует URL-адрес site.html/page.html. Поэтому при нажатии на «хэшевую» ссылку на вебстранице происходит переход на site.html/page.html.

Если – подробнее

На самом деле, ссылка

href="https://fsb**.com/pr**.php?u=eJw**LYD5DYqisWtkxB%2B8wF9toT4WlsPLIE77OPyJ09acpvIdjT7MM67oXiI7WD0xD">Ссылка</a>

является ссылкой на прокси-сервер (анонимайзер). То, что содержится в ней после знака «?», является командой для сервера (точнее, не для сервера, а для программы на языке РНР, содержащейся в файле pr**.php), указывающей, что необходимо открыть соответствующую страницу на сервере site.ru, обработать ее и передать клиенту (пользователю) в браузер.

Проблема 1

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

Примечание. Здесь мы немного отступаем от общепринятой терминологии, называя динамическими ссылками такие ссылки, которые формируются при помощи javascript. То же здесь относится и к адресам. Обычно же под динамическими понимаются такие адреса, которые могут меняться в зависимости от тех или иных условий.

Так вот, такие ссылки большинством анонимайзеров преобразованы НЕ БУДУТ. Для проверки можно сделать простую страницу html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
   <title>Тест анонимайзера</title>
   <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"/>
</head>
<body style="padding:0; margin:0;">
<br/><br/><br/>
<a href="http://www.dissertacii-diplom-ufa.ru">Ссылка HTML (статическая).</a><br/>
<a href="1">Ссылка JS (динамическая).</a><br/>
<a href="2">Ссылка JS (динамическая составная).</a><br/>
<script type="text/javascript">
var link0 = document.getElementsByTagName('a')[0];
var link1 = document.getElementsByTagName('a')[1];
link1.setAttribute('href', 'http://www.dissertacii-diplom-ufa.ru#');
var link2 = document.getElementsByTagName('a')[2];
link2.href = 'http://'+'dissertacii-diplom-ufa.ru';
alert(link0.href +'\n' +  link1.href + '\n' + link2.href);
</script>
</body>
</html>

После загрузки (обновления) этой страницы в браузере во всплывающем окне появится что-то вроде


Статические и динамические ссылки (html и javascript)

http://www.dissertacii-diplom-ufa.ru/
http://www.dissertacii-diplom-ufa.ru/#
http://dissertacii-diplom-ufa.ru/

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

Примечание. Страница загружалась с локального компьютера, поэтому в адресной строке браузера указан протокол file. Если же ее загрузить на хостинг, тогда она, конечно, будет доступна по протоколу http (или https).

Так вот, практика показывает, что через анонимайзер открываются лишь ссылки первого вида, т.е. статические. Тогда как при кликах на динамические – браузер либо не реагирует, либо «открывает» что-то совсем не то.

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

Насчет закона и законности. Еще раз, технология обсуждается только в научных целях, т.е. для тестирования - с одной стороны. С другой стороны, в настоящее время некоторые сайты блокируют даже без суда, а просто по чьему-то там указанию. Ну, да, приняли "закон", который позволяет это делать. А интересно, если еще "закон" примут, который, скажем, даст разрешение без суда и следствия стрелять из пулемента в каждого, кто пройдет в 0,45 м от края проезжей части? Или в каждого, кто, например, в среду в 13-32 выйдет из дома. Что будет?

Известно, что некоторые вебмастера предпочитают, иной раз, динамические ссылки вместо статических - в целях SEO. Мы, к примеру, подобными делами не занимаемся, ну, а так - есть такое, да. Так вот и нюанс для размышлений: или SEO, или анонимайзеры...

Проблема 2

Вторая проблема связана с первой. Дело в том, что применение анонимайзеров-онлайн может затруднять передачу сообщений на сайт, например, комментариев. Причина – та же самая: при отправке комментариев используется javascript-команда, содержащая URL-адрес программы (например, на языке РНР), которая примет комментарий от пользователя, обработает его и вставит на страницу, чтобы он стал доступным другим пользователям.

Одно дело, если адрес такой программы задан в скрипте статически, например так:

xhr.open("POST", 'site.ru/program.php', true);

Есть вероятность, что прокси-сервер, увидев URL, соответствующим образом преобразует его. Правда, это не факт, так как адрес содержится не в html-коде, а в скрипте. Но, тем не менее.

Совсем другое дело, если команда будет выглядеть следующим образом:

xhr.open("POST", docum_location+'/program.php', true);

где переменная docum_location может принимать, вообще говоря, разные значения (например, в зависимости от страны, из которой происходит запрос, адреса страницы, авторизован ли пользователь на сайте, ну, и т.п.). Типичный прокси-сервер (онлайн-анонимайзер), скорее всего, не сможет распознать такой адрес и правильно его преобразовать. Ибо для этой цели необходимо будет реализовать на сервере интерпретатор-анализатор javascript. А это – довольно сложная задача. Ведь даже современные поисковые системы – и то выполняют эту функцию не в полной мере.

В силу чего поисковики (тот же Яндекс) рекомендуют использование специальных метатегов, преобразование URL-адресов ссылок специальным образом, т.е. «костыли», как выражаются программисты. К тому же, это может помешать открытию страницы в старых не самых новых браузерах (ибо они не знают таких метатегов и не умеют преобразовывать адреса предложенным образом), что автоматически приведет к потере трафика.

Вот типичный вариант вопроса вебмастера и ответа на него службы поддержки Яндекса (взято из открытого доступа):

«…вопрос: у нас товары не находятся в коде страницы, мы их подгружаем через AJAX. В этом случае по-прежнему можно делать HTML-слепки?

Сотрудник Яндекса 13 ноября 2017, 10:32:
Да, в этом случае по-прежнему нужны статические копии.»

Следовательно, объект XMLHttpRequest и запросы, производимые им, будут направляться не на адрес вида

https://fsb**.com/pr**.php?u=eJw**LYD5DYqisWtkxB%2B8wF9toT4WlsPLIE77OPyJ09acpvIdjT7MM67oXiI7WD0xD

а на примерно такой адрес:

site.ru/some-url-components/program.php

Это означает, во-первых, что доменное имя может быть обнаружено провайдером и, соответственно, такой запрос будет заблокирован. Во-вторых, в силу того, что адреса страницы и запроса будут разными, браузер заблокирует такой запрос, как кроссдоменный. Дело в том, что в URL-адресе вебстраницы и в адресе запроса должны совпадать:

  1. Протокол,
  2. Домен,
  3. Порт.

Т.е. – нарушается второе условие.

Конечно, как вариант, можно подключать политику CORS, но это не есть хорошо – в общем случае. Да и не всегда возможно на практике.

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

Проблема 3

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

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

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

Проблема 4

Соответственно, скорее всего, на странице, открытой через анонимайзер, НЕ будет работать система слежения за действиями пользователей (если таковая имеется, конечно). Причин здесь две и они аналогичны тем, что приведены в описании проблемы 2.

Выводы

Иными словами, если принимать во внимание возможность работы с сайтом с применением анонимайзеров-онлайн, при разработке его страниц следует стремиться:

  1. К МИНИМАЛЬНОМУ объему контента, адреса которого (перед загрузкой) формируются динамически на стороне клиента.
  2. К минимуму динамических ссылок, если Вы хотите, чтобы пользователи могли переходить по ним. Критически важные ресурсы для страницы (например, файлы с основными стилями CSS, без которых страница может выглядеть нечитаемой), по возможности, должны иметь статические адреса.
  3. По возможности, НЕ использовать технологию AJAX для подгрузки контента страницы. Целесообразнее, все же, использовать AJAX для более актуальных вещей – для отправки сообщений на сервер, т.е. именно для того, для чего он и предназначен, в первую очередь. Это даст возможность пользователям, по крайней мере, если не отправить сообщение, то, хотя бы, прочитать контент страницы.

Или, если более коротко, окончательный вывод: если уж есть необходимость в динамических URL-адресах на вебстранице, в динамическом формировании контента, то целесообразнее, чтобы все это формировалось (по возможности) сервером – еще перед тем, как отдавать html-код страницы, а не клиентом. Так будет больше возможностей для сайта быть доступным через прокси-серверы типа анонимайзеров-онлайн, которые изменяют URL, содержащиеся на страницах. Да и для поисковых роботов будет меньше неудобств и, следовательно, меньше ошибок при индексировании сайта.

Правда, есть еще анонимайзеры иного вида. Которые подменяют лишь IP-адрес пользователя (и, быть может, некоторые HTTP-заголовки), открывающего страницу сайта и передают через себя эту страницу – без ее изменения. К ним все вышесказанное не имеет отношения, так как они не меняют URL, присутствующие на страницах, равно как и URL самой открываемой страницы. Такие прокси-серверы для обхода защиты от просмотра «запрещенных» сайтов, зачастую, бесполезны. Впрочем, не все провайдеры «заглядывают» в html-код открываемых пользователями вебстраниц.

Комментарии:
Всего комментариев:0
Пожалуйста, не забудьте ознакомиться с правилами оставления комментариев.



Подписаться на комментарии на этой странице

Мы можем выполнить

Другие услуги
Интересная и полезная
информация