999 Код ошибки в запросе HEAD для LinkedIn

Мы используем curl HEAD-запрос в приложении PHP для проверки достоверности общих ссылок. Мы проверяем код состояния только для того, чтобы убедиться, что ссылка, введенная пользователем, действительна. Ссылки на все сайты преуспели, кроме LinkedIn.

Пока он работает локально (Mac), когда мы пытаемся выполнить запрос с любого из наших серверов Ubuntu, LinkedIn возвращает код состояния 999. Не API-запрос, просто простой завиток, как мы делаем для каждой другой ссылки. Мы пробовали на нескольких разных машинах и пытались изменить пользовательский агент, но не играли в кости. Как изменить наш завиток, чтобы рабочие ссылки возвращали 200?

Пример запроса HEAD:

curl -I --url https://www.linkedin.com/company/linkedin

Пример ответа на машину Ubuntu:

HTTP/1.1 999 Request denied
Date: Tue, 18 Nov 2014 23:20:48 GMT
Server: ATS
X-Li-Pop: prod-lva1
Content-Length: 956
Content-Type: text/html

Откликнуться на @alexandru-guzinschi немного лучше. Мы пробовали маскировать User Agents. Подводя итог нашим исследованиям:

Mac машина + Mac UA = > работает
Mac машина + Windows UA = > работает
Удаленный компьютер Ubuntu + (без изменения UA) = > не работает
Удаленный компьютер Ubuntu + Mac UA = > не работает
Удаленный компьютер Ubuntu + Windows UA = > не работает
Локальная виртуальная машина Ubuntu (на Mac) + (без изменения UA) = > не работает
Локальная виртуальная машина Ubuntu (на Mac) + Windows UA = > работает
Локальная виртуальная машина Ubuntu (на Mac) + Mac UA = > работает

Итак, теперь я думаю, что они блокируют любые запросы на завиток, которые не предоставляют альтернативный UA, а также блокируют хостинг-провайдеров?

Есть ли другой способ проверить, действительно ли ссылка на linkedin является действительной или приведет к их 404 странице, с компьютера Ubuntu с использованием PHP?

Ответ 1

Похоже, что они фильтруют запросы на основе пользовательского агента:

$ curl -I --url https://www.linkedin.com/company/linkedin | grep HTTP
HTTP/1.1 999 Request denied

$ curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3" -I --url https://www.linkedin.com/company/linkedin | grep HTTP
HTTP/1.1 200 OK

Ответ 2

Я нашел обходной путь, важно установить заголовок accept-encoding:

curl --url "https://www.linkedin.com/in/izman" \
--header "user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36" \
--header "accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" \
--header "accept-encoding:gzip, deflate, sdch, br" \
| gunzip

Ответ 3

Похоже, что LinkedIn фильтрует как пользовательский агент, так и IP-адрес. Я пробовал это как дома, так и из Digital Ocean node:

curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3" -I --url https://www.linkedin.com/company/linkedin

Из дома я получил 200 OK, от DO я получил 999 Denied...

Итак, вам нужен прокси-сервис, например HideMyAss или другой (не проверял его, поэтому я не мог сказать, действительно ли он действителен или не). Здесь - хорошее сравнение прокси-сервисов.

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

Ответ 4

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

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

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