Code D'erreur 999 sur la demande de tête à LinkedIn
nous utilisons une requête curl HEAD dans une application PHP pour vérifier la validité des liens génériques. Nous vérifions le code d'État pour nous assurer que le lien saisi par l'utilisateur est valide. Les liens vers tous les sites Web ont réussi, à l'exception de LinkedIn.
alors que cela semble fonctionner localement (Mac), lorsque nous tentons la requête de l'un de nos serveurs Ubuntu, LinkedIn renvoie un code de statut 999. Pas une requête API, juste une simple boucle comme nous le faisons pour tous les autres liens. Nous avons essayé sur quelques différentes machines et essayé de modifier l'agent utilisateur, mais pas de dé. Comment puis-je modifier notre boucle pour que les liens de travail renvoient un 200?
Un exemple de TÊTE de demande:
curl -I --url https://www.linkedin.com/company/linkedin
Exemple de Réponse sur la machine 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
pour répondre un peu mieux à @alexandru-guzinschi. Nous avons essayé de masquer les agents utilisateurs. Pour résumer nos essais:
- Mac machine + Mac UA =>
- Mac de la machine + Windows UA =>
- Ubuntu machine distante + (n UA changement) => n'
- Ubuntu machine distante + Mac UA => n'
- Ubuntu machine distante + Windows UA => n'
- Ubuntu local de la machine virtuelle (sur Mac) + (n UA changement) => n'
- Ubuntu local de la machine virtuelle (sur Mac) + Windows UA =>
- Ubuntu local de la machine virtuelle (sur Mac) + Mac UA =>
donc maintenant je pense qu'ils bloquent toutes les requêtes curl qui ne fournissent pas d'UA alternative et bloc de fournisseurs d'hébergement?
y a-t-il un autre moyen de vérifier si un lien vers linkedin est valide ou s'il mènera à leur page 404, à partir d'une machine Ubuntu utilisant PHP?
4 réponses
on dirait qu'Il filtre les requêtes en fonction du user-agent:
$ 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
j'ai trouvé la solution, important de mettre en-tête 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
ressemble à LinkedIn filtre à la fois l'agent utilisateur et l'adresse ip. J'ai essayé cela à la fois à la maison et à partir D'un nœud Océanique numérique:
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
à Partir de la maison, j'ai un 200 OK, de FAIRE j'ai eu 999 Refusé...
Vous avez donc besoin d'un service proxy comme HideMyAss ou autre (Je ne l'ai pas testé donc je ne peux pas dire si c'est valide ou pas). Ici est une bonne comparaison des services de proxy.
Ou vous pouvez configurer un proxy sur votre réseau domestique, par exemple, utiliser un Raspberry PI pour proxy vos demandes. Ici est un guide à ce sujet.
Proxy fonctionnerait, mais je pense qu'il y a une autre solution. Je vois que D'après AWS et d'autres nuages il est bloqué par IP. Je peux émettre la demande de ma machine et ça marche très bien.
j'ai remarqué que dans la réponse du service cloud, il renvoie quelques JS que le navigateur doit exécuter pour vous amener à une page de connexion. Une fois sur place, vous pouvez vous connecter et accéder à la page. La page de connexion est réservée à ceux qui accèdent via une adresse IP bloquée.
Si vous utilisez une client sans tête qui exécute JS, ou peut-être aller directement vers le lien suivant et fournir les informations d'identification d'un utilisateur linkedin, vous pouvez être en mesure de le contourner.