We gebruiken een curl HEAD-verzoek in een PHP-toepassing om de geldigheid van generieke links te verifiëren. We controleren de statuscode om er zeker van te zijn dat de link die de gebruiker heeft ingevoerd geldig is. Links naar alle websites zijn gelukt, behalve LinkedIn.
Hoewel het lokaal (Mac) lijkt te werken, retourneert LinkedIn een 999 statuscode wanneer we het verzoek van een van onze Ubuntu-servers proberen. Geen API-verzoek, gewoon een simpele krul zoals we voor elke andere link doen. We hebben op een paar verschillende machines geprobeerd en geprobeerd de user-agent te veranderen, maar geen dobbelstenen. Hoe pas ik onze krul aan zodat werkende links een 200 retourneren?
Een voorbeeld van een HEAD-verzoek:
curl -I --url https://www.linkedin.com/company/linkedin
Voorbeeldreactie op Ubuntu-machine:
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
Om een beetje beter te reageren op @alexandru-guzinschi. We hebben geprobeerd de User Agents te maskeren. Om onze proeven samen te vatten:
- Mac-machine + Mac UA => werkt
- Mac-machine + Windows UA => werkt
- Externe Ubuntu-machine + (geen UA-wijziging) => mislukt
- Externe Ubuntu-machine + Mac UA => mislukt
- Externe Ubuntu-machine + Windows UA => mislukt
- Lokale virtuele Ubuntu-machine (op Mac) + (geen UA-wijziging) => mislukt
- Lokale virtuele Ubuntu-machine (op Mac) + Windows UA => werkt
- Lokale virtuele Ubuntu-machine (op Mac) + Mac UA => werkt
Dus nu denk ik dat ze curl-verzoeken blokkeren die geen alternatieve UA bieden en ookhostingproviders blokkeren?
Is er een andere manier waarop ik kan controleren of een link naar linkedin geldig is of dat deze naar hun 404-pagina zal leiden, vanaf een Ubuntu-machine met PHP?
Antwoord 1, autoriteit 100%
Het lijkt erop dat ze verzoeken filteren op basis van de 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
Antwoord 2, autoriteit 54%
Ik heb de oplossing gevonden,
belangrijk om de accept-encoding header in te stellen:
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
Antwoord 3, autoriteit 17%
Het lijkt erop dat LinkedIn zowel de user-agent als het ip-adres filtert. Ik heb dit zowel thuis als vanaf een Digital Ocean-knooppunt geprobeerd:
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
Van thuis kreeg ik een OK van 200, van DO kreeg ik 999 geweigerd…
Je hebt dus een proxyservice nodig zoals HideMyAssof iets anders (heb het niet getest, dus ik kon het niet zeggen of het geldig is of niet). Hieris een goede vergelijking van proxyservices.
Of u kunt een proxy instellen op uw thuisnetwerk, bijvoorbeeld een Raspberry PI gebruiken om uw verzoeken te proxyen. Hier is daar een gids over.
Antwoord 4, autoriteit 17%
Proxy zou werken, maar ik denk dat er een andere manier is. Ik zie dat van AWS en andere clouds dat het wordt geblokkeerd door IP. Ik kan het verzoek vanaf mijn machine doen en het werkt prima.
Ik merkte in het antwoord van de cloudservice dat het een aantal JS retourneert die de browser moet uitvoeren om je naar een inlogpagina te brengen. Eenmaal daar kunt u inloggen en toegang krijgen tot de pagina. De inlogpagina is alleen voor degenen die toegang hebben via een geblokkeerd IP-adres.
Als je een headless-client gebruikt die JS uitvoert, of misschien rechtstreeks naar de volgende link gaat en de inloggegevens van een linkedin-gebruiker opgeeft, kun je deze mogelijk omzeilen.