2013-02-05 26 views
10

Działamy skracania adresów URL, w ciągu ostatniego tygodnia albo tak zaczęliśmy widzieć mnóstwo dziwnych wniosków o {normal url}/no_facebook_preview_picture.jpg z Facebook posiadanych adresów IP i agenta użytkownika facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)Facebook wnioski o {url} /no_facebook_preview_picture.jpg na 404 linków

gdybym zakładać normalny link do naszej strony na ścianie (ustawiony jako Only Me więc mogę przetestować) pojawia się następujący wpis w naszym dzienniku dostępu

66.220.152.6 - - [05/Feb/2013:16:31:36 +0000] "GET /44_U HTTP/1.1" 200 1314 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

jednak gdybym umieścić link, który zwraca 404 lub 410 (link do spamu usunięty po utworzeniu) Otrzymuję to

69.171.237.15 - - [05/Feb/2013:16:49:16 +0000] "GET /notexistURL HTTP/1.1" 404 1319 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

następnie w ciągu godziny lub tak

173.252.110.113 - - [05/Feb/2013:17:15:15 +0000] "GET /notexistURL/no_facebook_preview_picture.jpg HTTP/1.1" 404 0 "-" "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

whois tego IP informuje

NetName FACEBOOK-INC 
NetHandle NET-173-252-64-0-1 

więc są one zdecydowanie Facebook IPS.

Otrzymujemy około 10-20 takich wniosków dziennie, wszystkie identyczne. Możemy odzyskać tylko pliki z datą 7 dni, ale wnioski te miały miejsce 7 dni temu.

Testowałem linki, które są wyjątkowe, więc nie ma innego sposobu na znalezienie linku. Nie korzystam z Facebooka tak bardzo, a wszystkie z wyjątkiem moich testowych linków zostały utworzone/opublikowane przez innych użytkowników, ale rozpoznaję wszystkie aplikacje powiązane z moim kontem na Facebooku i nie ma w nich nic niezwykłego, więc nie sądzę, że to jest strona trzecia app (mogę przedstawić listę jeśli potrzebne, ale są one wszystkie aplikacje wielkie nazwisko)

podczas mojego badając plików dziennika, Facebook nawet nie wydaje się być tworzenie te żądania inteligentnie, to tylko ślepo trzymać ciąg /no_facebook_preview_picture.jpg na końcu adresów URL, nawet z ciągami zapytań. Na przykład;

69.171.228.114 - - [05/Feb/2013:17:19:13 +0000] "GET /iAmNotARealURL1234777?ref=fb&cows_go=moo HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 
69.171.228.114 - - [05/Feb/2013:17:19:13 +0000] "GET /iamnotarealurl1234777 HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 
173.252.103.4 - - [05/Feb/2013:17:44:41 +0000] "GET /iAmNotARealURL1234777?ref=fb&cows_go=moo/no_facebook_preview_picture.jpg HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

Google wydaje się wyświetlać wiele przypadkowych wyników, głównie z pomysłodawców łącza, ale nie mogłem znaleźć żadnych informacji, co te wnioski są.

Jakie są te prośby? Do czego Facebook ich potrzebuje? Czy jest to błąd w naszej aplikacji, czy te żądania mogą być bezpiecznie ignorowane?

Aktualizacja:

Kilka dni mamy teraz coraz 2-3 sto trafień do tych adresów

[[email protected] nginx]$ for DAYLOG in `find ./ | grep "dftbashort.log-"`; do COUNT=`cat $DAYLOG | grep no_facebook_preview_picture | wc -l`; echo "${DAYLOG} has ${COUNT} occurences"; done 
./dftbashort.log-20130201 has 0 occurences 
./dftbashort.log-20130130 has 2 occurences 
./dftbashort.log-20130129 has 2 occurences 
./dftbashort.log-20130128 has 2 occurences 
./dftbashort.log-20130202 has 378 occurences 
./dftbashort.log-20130207 has 222 occurences 
./dftbashort.log-20130205 has 257 occurences 
./dftbashort.log-20130209 has 178 occurences 
./dftbashort.log-20130131 has 2 occurences 
./dftbashort.log-20130203 has 266 occurences 
./dftbashort.log-20130206 has 667 occurences 
./dftbashort.log-20130204 has 12 occurences 
./dftbashort.log-20130127 has 4 occurences 
./dftbashort.log-20130208 has 260 occurences 

Nie udzielamy żadnych open-Graph meta tagi, a strona nie ma treści inne niż przekierowanie meta/javascript.

Odpowiedz

2

Jestem całkiem pewien, że to skrobak akcji stara się budować podgląd adresu URL, uruchom URL poprzez Facebook's Debug Tool a zobaczysz co widzi Facebook/poszukuje

Nie jestem pewien, co żądania /notexistURL/no_facebook_preview_picture.jpg są, zakładając, że nic w kodzie nie wskazuje na taki adres URL; Gdybym musiał zgadywać, powiedziałbym, że był to rodzaj domyślnego lub awaryjnego użycia, gdy nie ma meta tagów; być może błąd - jestem dość pewny, że jeśli umieścisz poprawne metatagi na Facebooku, to złapie je, a nie złoży nieprawidłowe żądania, a dodatkową korzyścią będzie to, że udziały twoich adresów URL wyglądają lepiej na Facebooku.com i inne strony, które obsługują te same tagi

+0

Tak, rozumiem robota na Facebooku, jest w porządku i otrzymujemy z niego mnóstwo odsłon, aby rozszerzyć adresy URL, które skróciliśmy. Odkąd napisałem ten post, otrzymujemy setki zgłoszeń dziennie dla tych adresów URL 'no_facebook_preview_picture' = (https://gist.github.com/samarudge/0c4a040c389c5b339278 – Smudge

0

Wpadłem na to samo dziś rano i trochę kopałem. Możesz skorzystać z informacji pod numerem this site, aby pomóc Ci we właściwym kierunku. Wygląda na to, że pomógł mi zabić moją witrynę tymi błędami.

+0

Twoja" odpowiedź "w dużej mierze składa się wyłącznie z linku zewnętrznego. Proszę [patrz tutaj] (http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers) w celu omówienia niektórych rodzajów odpowiedzi. .. – Lix

+0

Witam, właściciel strony, tutaj mogę zapewnić, że AgentPhoenix i ja nie jesteśmy tą samą osobą Mój blog jest powiązany z witrynami publicznymi SharePoint, ale niektóre z nich mogą być przydatne dla ludzi. Zgadzam się z @Igy (przegłosowane) - użyj narzędzia do debugowania Facebooka i powie Ci, czego szuka. Posiadanie dobrych metadanych dla twojej publicznej strony jest dobre dla wszystkich wyszukiwarek, agentów wyszukiwania i Facebooka. –