конечная ссылка API службы сокращения URL-адресов попадает в цель

Я использовал службы сокращения URL-адресов, такие как goo.gl или bit.ly, для сокращения длинных URL-адресов в своих приложениях с использованием соответствующих API-интерфейсов. Эти API очень удобны, но, к сожалению, я заметил, что длинный URL-адрес попадает в цель, когда они его сокращают. Позвольте мне немного объяснить мою проблему. Допустим, например, что я хочу, чтобы пользователи что-то проверяли (например, адрес электронной почты или подтверждение), и предлагаю им в моем приложении ссылку, по которой они могут перейти, чтобы что-то подтвердить. Я беру этот длинный URL-адрес и использую API, чтобы сократить его. Целевая ссылка (например, PHP-скрипт) срабатывает, когда я вызываю укороченный API, что делает процесс проверки бесполезным.

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

Я хотел бы знать, если кто-нибудь уже столкнулся с этой проблемой, если кто-нибудь знает, как ее решить.

Спасибо за помощь.


person Raphael C    schedule 28.09.2014    source источник
comment
В любом случае вы должны проверять все данные, передаваемые PHP-скрипту, а не просто разрешать данные из любого места.   -  person ggdx    schedule 28.09.2014


Ответы (1)


Я не могу говорить с Google, но в Bitly мы сканируем часть URL-адресов, сокращенных с помощью нашего сервиса, для поддержки различных функций продукта (проверка спама, получение заголовков и т. д.), что является причиной поведения, которое вы видите.

В такой ситуации мы даем две рекомендации:

  1. Используйте robots.txt, чтобы пометить соответствующие пути как "запрещенные". Это легкая форма защиты, так как ничто не заставляет клиентов уважать robots.txt, но боты с хорошим поведением, такие как BitlyBot или GoogleBot, будут уважать ваш файл robots.txt.
  2. Как упоминалось dwhite.me в комментарии и как вы признали в своем посте, обычно лучше не выполнять никаких действий по изменению состояния в ответ на запросы GET. Как всегда, необходимо оценить риски, связанные с добавленной сложностью более безопасного подхода.
person SeanOC    schedule 28.09.2014
comment
Спасибо за Ваш ответ. Я попытаюсь реализовать robots.txt, как вы рекомендовали. Относительно решения об изменении состояния запроса GET: в этой конкретной ситуации время между моментом сокращения URL-адреса и моментом посещения пользователем URL-адреса должно быть относительно коротким, и cron удаляет и аннулирует эти ссылки. время от времени. Но, как я уже говорил ранее, добавление кнопки подтверждения на эту страницу только усложняет процесс проверки. Здесь важно сохранить клик. - person Raphael C; 29.09.2014
comment
Я также подумал о том, чтобы установить локальную переменную cookie на стороне клиента и проверить этот файл cookie при проверке, ограничивая пользователей для принятия файла cookie и проверки с одного и того же устройства. - person Raphael C; 29.09.2014