Comments 31
Достаточно было бы проверять не только наличие файла, но и его содержимое
+53
На деле это решение все равно потребовало бы от вебмастеров переподтверждения. Потому поддерживаю Яндекс, смысла в этом способе нет, если подтверждение через HTML по сути то же самое.
+11
чем отличается от проверки HTML файла? и как это поможет человеку с тысячей сайтов, если раньше достаточно было пустого файла?
+2
В HTML файл надо положить определённую строку, которую тоже даёт яндекс (и которую он тоже проверяет).
+2
через несколько дней после отправленного отчёта, судьба txt-фала была решена (R.I.P.):
И что во всем яндексе не нашлось человека который предложил бы создавать txt-файл с каким либо содержимым, каким-нибудь хэшем, как это делают все остальные, а не надеяться на код ответа сервера.
+29
Я думаю, вскоре появится. Странно конечно, что с самого начала это не сделали, но сейчас им нужно все согласовать, прописать стандарты и так далее. В таких компаниях, как яндекс дажи такие незначительные изменения так быстро не делаются.
+1
Т.е. чтобы выпилить фичу никаких согласований не требуется, а внести простое исправление нужно месяцы? Да и в тексте указано «решение отказаться».
+1
Выпилить фичу — это просто решение менеджера. А вот ввести новую фичу — решение команды. Поэтому первое и быстрее, чем второе. Но так, да. Неправильно это.
+2
Выпилить фичу — это закрыть известный баг. При наличии альтернатив — это, конечно, не очень удобно, но не фатально.
Добавить фичу, не согласовав с остальными отделами/проектами/и т.д. — это добавить 10 неизвестных багов. Может отвалиться что угодно — например, подтверждение для Директа или еще чего. В итоге заранее неопределенный круг пользователей может оказаться под угрозой.
Думаю именно так и появилось подтверждение через текстовый файл. Есть полная процедура — через html-файл с проверкой содержимого. Решение ввести упрощенную схему выглядит совершенно логично — веб-мастер контролирует содержимое своего сайта, он может создать файл с особым именем и записать туда что-то. Начинаем оптимизировать. Если вебмастер уже создал файл, то зачем проверять содержимое? Логично? Весьма. Внутри системы изъяна нет. Проблема начинается при «интеграционном тестировании» с интернетом. Практически все распространенные системы ведут себя как положено. Но есть особый баг в ряде CMS, где наличие файла можно сымитировать.
Добавить фичу, не согласовав с остальными отделами/проектами/и т.д. — это добавить 10 неизвестных багов. Может отвалиться что угодно — например, подтверждение для Директа или еще чего. В итоге заранее неопределенный круг пользователей может оказаться под угрозой.
Думаю именно так и появилось подтверждение через текстовый файл. Есть полная процедура — через html-файл с проверкой содержимого. Решение ввести упрощенную схему выглядит совершенно логично — веб-мастер контролирует содержимое своего сайта, он может создать файл с особым именем и записать туда что-то. Начинаем оптимизировать. Если вебмастер уже создал файл, то зачем проверять содержимое? Логично? Весьма. Внутри системы изъяна нет. Проблема начинается при «интеграционном тестировании» с интернетом. Практически все распространенные системы ведут себя как положено. Но есть особый баг в ряде CMS, где наличие файла можно сымитировать.
+8
HTML-файл делает по сути то же самое
Скриншот
+8
как это делают все остальные
А кого Вы имеете ввиду, когда пишете «все остальные»?
Не могли бы вы рассказать — у каких других вебмастерских сервисов есть «подтверждение через текстовые файлы»? Я может быть плохо искал?
0
Не обязательно вебмастерские, любые другие сервисы которые требуют подтверждение владением сайта. А это различные конторы выдающие SSL-сертификаты, рекламные сети, платежные системы и т.п. Да у самого Яндекса есть проверка по html, или чтобы найти на сайте нужный хэш его обязательно нужно в html заворачивать?
0
Заплатили за уязвимость?
-19
Являясь закоренелым любителем почитать логи...
К сожалению, я не большой любитель копания кода...
Почему я замечаю, такие ненужные факты об авторе?!
-19
В чем магия чисел 41337 313373?
+5
true h4x0r leet-speak
1337 = leet
1337 = leet
+8
Это были времена, когда в половине программ русский шрифт не поддерживался и «cool-][ацкеры» изгалялись с написанием собственных ников любыми способами. Хотя память мне подсказывает, что 31337 началось гораздо раньше и появилось ещё во времена Митника за Океаном. В общем, было дело, 31337 читали как eleet, аля «элитный» (хотя элита и пишется через i). А автор, видимо, с последней тройкой просто ошибся.
+3
Не покидает мысль, что в таком случае содержимое txt (и html) файла, которое однозначно определяется именем, не имеет особого значения.
Труда не составит и сформировать корректное «содержимое» файла с именем yandex_0123456ABCDEF.html в виде
Тоесть на запрос бота яндекса, легко отдается «корректный» проверочный файл. Хорошая идея для плагина вордпресса — «автоподтвержение в яндексе».
Труда не составит и сформировать корректное «содержимое» файла с именем yandex_0123456ABCDEF.html в виде
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>Verification: 0123456ABCDEF<</body>
</html>
Тоесть на запрос бота яндекса, легко отдается «корректный» проверочный файл. Хорошая идея для плагина вордпресса — «автоподтвержение в яндексе».
+1
А как сайт узнает, на какой из 20 запросов бота яндекса, нужно ответить верным кодом? фишка подтверждения, что их этих запросов какой-то случайный есть с реальным кодом, остальные — нет.
+1
UFO just landed and posted this here
сам по себе не причём,
НИ при чем*
-3
UFO just landed and posted this here
>имел место быть
это тавтология, достаточно сказать «имел место» или просто «был»
это тавтология, достаточно сказать «имел место» или просто «был»
-1
Sign up to leave a comment.
Почему Яндекс отказался от подтверждения сайтов txt-файлом