Bruke leserens ip-adresse
- Trådstarter kongen
- Startdato
adeneo
Medlem
Da er det brukerens IP adresse som vises, men javascript i nettleseren er underlagt Same-origin policy, og har ikke tilgang til eksterne nettsider, annet enn dersom CORS er slått på, eller innholdet er JSONP.
Pong
Jeg selger sʇɥƃıluʍop :)
Man kan vel starte chrome med --disable-web-security
kongen
kongemedlem
Denne CORS-tingen, er det noe som må være påslått på min server, slik at dette kan fikses enkelt, eller må det være påslått på serveren jeg scraper fra?
Finnes det noen browserteknologi unntatt javascript som kan løse dette, slik at de som har javascript avslått ikke blir utelatt?
Bruker ikke disse xml-feeds? De jeg skal scrape fra har ikke slikt.
Lage et script som autostarter chrome på leserens pc?
Hva er hurtigst for scraping, bruker minst ressurser, og er minst detektbar av curl eller file_get_contents med stream_context?
Hvis man skal scrape noe som befinner seg innen en div, må man scrape hele siden for så å "klippe ut" div, eller kan man scrape bare div når den har en id?
adeneo
Medlem
CORS må være "slått på" på den serveren du scraper fra, slik at det utelukker det meste.
Det finnes ikke noe teknologi eller lureri for å komme rundt same-origin policy'en, den er der for å nettopp sikre at nettsider ikke laster ned innhold fra eksterne nettsider rett inn i nettleseren.
Løsningen er å bruke din egen server til å scrape med, ettersom det kun er nettlesere som er underlag policy'en.
Som regel er det ikke noe problem med IP adressen, og det er alltid en mulighet å bruke en eller flere proxier.
Raskest og minst detektbart er no cURL, hvor du setter headern slik at den er lik som en vanlig nettleser, da er det så godt som umulig å se forskjell i serverloggene til de du scraper.
Når du scraper laster du ned hele filen og så parser du filen med noe som kan lese HTML og "klipper" ut elementer på den måten.
Det finnes også alternativer for å streame filer, og så lese de etterhvert som de lastes inn, men det benyttes sjeldent.
Det finnes ikke noe teknologi eller lureri for å komme rundt same-origin policy'en, den er der for å nettopp sikre at nettsider ikke laster ned innhold fra eksterne nettsider rett inn i nettleseren.
Løsningen er å bruke din egen server til å scrape med, ettersom det kun er nettlesere som er underlag policy'en.
Som regel er det ikke noe problem med IP adressen, og det er alltid en mulighet å bruke en eller flere proxier.
Raskest og minst detektbart er no cURL, hvor du setter headern slik at den er lik som en vanlig nettleser, da er det så godt som umulig å se forskjell i serverloggene til de du scraper.
Når du scraper laster du ned hele filen og så parser du filen med noe som kan lese HTML og "klipper" ut elementer på den måten.
Det finnes også alternativer for å streame filer, og så lese de etterhvert som de lastes inn, men det benyttes sjeldent.
Pong
Jeg selger sʇɥƃıluʍop :)
CORS er vel noe som nettleseren, eller user-agent (som mozilla, chrome, curl) må implementere?
For chrome kan du slå det av slik: http://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome
Det betyr at du kan kjøre scripts som gjør hva som helst fra din chrome client. Din klient's IP-adresse utad vil da blir vist til serveren du scraper fra.
For chrome kan du slå det av slik: http://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome
Det betyr at du kan kjøre scripts som gjør hva som helst fra din chrome client. Din klient's IP-adresse utad vil da blir vist til serveren du scraper fra.
Er jo mulig å injisere en iframe med javascript for eksempel. Man må jo ikke bruke XMLHttpRequest for å laste innhold fra et annet domene, og det er kun XMLHttpRequest objekt som er underlagt CORS, så man kan jo i praksis gjøre GET requests uten å bry seg om CORS headere. POST/PUT er verre.
Når jeg tenker over det, hvis man bruker en reverse proxy foran serveren man vil POSTe til, så kan man jo også manipulere response headerne i et slags man in the middle angrep og dermed forbigå CORS. Ikke testet det, men kan ikke se hvordan det ikke skulle gått?
adeneo
Medlem
Nei, CORS er Cross Origin Resource Sharing, og det er en standard som "slås på" ved at serveren sender headere som angir hvem som kan laste ned informasjon med en nettleser.
For eksempel for å tillate alle er det vanlig at serveren sender
Kode:
Access-Control-Allow-Origin: *Man trenger ikke aktivere noe i nettleseren, og brukeren trenger ikke gjøre noe som helst, det virker ut av boksen dersom serveren man kontakter sender rette header'n.
Dette er eneste måten man kan gjøre en ajax forespørsel til en ekstern nettside uten at man får problemer med Same-Origin policy.
JSONP er også et alternativ, men det er ikke ajax i det hele tatt, men en script tag som settes inn, og scripts kan inkluderes fra eksterne kilder, akkurat som man inkluderer scripts fra en CDN osv. det finnes ingen begrensninger på det, men det hjelper lite her, ettersom det kun er snakk om JSON inne i en funksjon.
CORS gjør at man kan omgå Same-Origin policy'en, men det krever altså at man har kontroll over serveren man kontakter, eller at den allerede har aktivert CORS, noe vanlige nettsider ikke gjør.
Man kan selvfølgelig slå av sikkerheten i nettleseren og også Same-Origin policy'en, men de færreste brukere gjør det, og å kreve at brukeren endrer på grunninnstillinger som er gjeldende i alle nettlesere for å bruke en nettside fungerer vanligvis dårlig.
iFrame's er også underlagt Same-Origin Policy, og du har ikke tilgang til innholdet i en iFrame som laster inn en side fra en ekstern kilde hvor port, domene eller protokoll ikke stemmer med den nåværende siden.
iFrame'en vises selvfølgelig, men du kan ikke hente innholdet i iFrame'en med javascript, med mindre innholdet er fra din egen side, og således er du akkurat like langt.
Reverse Proxy er en mulighet, men da snakker vi om et system hvor du egentlig gjør ajax forespørsler til din egen server, slik at port, domene og protokoll matcher, og at serveren proxier forespørselen ut eksternt.
Det blir i grunn det samme som å sende en ajax request til egen server, med et PHP script som henter en ekstern nettside og sender den tilbake til ajax'en, og det er selvfølgelig ikke noe problem, serveren er ikke underlagt noen restriksjoner, det er det kun nettleseren som er, men IP adressen vil fremdeles være serverens ettersom det er den som gjør forespørselen, ikke brukerens nettleser.
Sist redigert:
kongen
kongemedlem
Ettersom innholdet ikke er JSONP, og CORS er noe jeg ikke kan slå på på de eksterne serverne, så må det bli curl med plenty av egne ip-adresser som roterer da.
Men hvis jeg kobler alle ip-adressene til en server, og la oss si jeg skal scrape vgnett, vil ikke vg da kunne se at det faktisk er en webserver (og den samme webserveren) bak alle ip-adressene? Vil de ikke fatte mistanke når isp for iPhone-besøkende er f.eks. Domeneshop? Og hvis jeg bruker diverse proxier, vil ikke vg kunne se at det er en proxy ved å se på hvilke porter som er åpne på ip-adressen?
Er det mulig i det heletatt å scrape en webside uten å legge igjen suspekte spor?
Men hvis jeg kobler alle ip-adressene til en server, og la oss si jeg skal scrape vgnett, vil ikke vg da kunne se at det faktisk er en webserver (og den samme webserveren) bak alle ip-adressene? Vil de ikke fatte mistanke når isp for iPhone-besøkende er f.eks. Domeneshop? Og hvis jeg bruker diverse proxier, vil ikke vg kunne se at det er en proxy ved å se på hvilke porter som er åpne på ip-adressen?
Er det mulig i det heletatt å scrape en webside uten å legge igjen suspekte spor?
adeneo
Medlem
IP adresser gies til ISP'er og hoster som en pool, altså fra ett nummer til ett annet, og et firma kan selvfølgelig ha flere pools med IP'er, slik at det er nok mulig å se at IP adressene tilhører samme firma, men det er mye greier.
For at de du skal scrape skal kunne sjekke om det er en webserver, så må de jo faktisk gjøre en forespørsel tilbake til webserveren, og det sitter normalt ingen i andre enden og finleser serverlogger og sjekker hvem som besøker siden deres.
Så er spørsmålet, hvor interessant er det for for eksempel VG å sjekke dette?
Dersom du henter deres nettside et par ganger daglig, så vil du vel knapt dukke opp i statistikken, og selv om du laster ned sider fra VG hvert tiende minutt, så utgjør du promille av trafikken deres, og de vil sannsynligvis ikke gidde å bruke ressurser på deg i det hele tatt, selv om du bruker den samme IP adressen hver gang.
Forsøker du derimot å laste ned 5000 forskjellige sider fra VG hvert eneste sekund, så vil du være en trussel, og de vil sannsynligvis svarteliste deg.
Enkelte, slik som Google, har avanserte automatiske systemer som oppdager forespørsler gjort automatisk med faste timere og slikt, og kjenner igjen oppførsel som ikke er "menneskelig", og vil nesten alltid oppdage deg uansett hva du prøver på. Trikset med slike sider er å vise litt høflighet å spre scrapingen utover et såpass stort tidsrom at de ikke bryr seg.
For at de du skal scrape skal kunne sjekke om det er en webserver, så må de jo faktisk gjøre en forespørsel tilbake til webserveren, og det sitter normalt ingen i andre enden og finleser serverlogger og sjekker hvem som besøker siden deres.
Så er spørsmålet, hvor interessant er det for for eksempel VG å sjekke dette?
Dersom du henter deres nettside et par ganger daglig, så vil du vel knapt dukke opp i statistikken, og selv om du laster ned sider fra VG hvert tiende minutt, så utgjør du promille av trafikken deres, og de vil sannsynligvis ikke gidde å bruke ressurser på deg i det hele tatt, selv om du bruker den samme IP adressen hver gang.
Forsøker du derimot å laste ned 5000 forskjellige sider fra VG hvert eneste sekund, så vil du være en trussel, og de vil sannsynligvis svarteliste deg.
Enkelte, slik som Google, har avanserte automatiske systemer som oppdager forespørsler gjort automatisk med faste timere og slikt, og kjenner igjen oppførsel som ikke er "menneskelig", og vil nesten alltid oppdage deg uansett hva du prøver på. Trikset med slike sider er å vise litt høflighet å spre scrapingen utover et såpass stort tidsrom at de ikke bryr seg.
Pong
Jeg selger sʇɥƃıluʍop :)
Så... hvor er single origin policy'en implementert? Det må vel være i user agent (webklienter som chrome), som sørger for at et nedlastet skript fra en eller annen nettside ikke begynner å herje og laster ned fra masse andre sider (med mindre disse sidene har en cors-header som sier det er ok).
Hvis klienten er chrome kan man altså slå av denne begrensningen, og da kan kongen scrape "så mye han vil" med script som han kjører i sin chrome client.
Men det kan også være at jeg må tenke om igjen?
Hvis klienten er chrome kan man altså slå av denne begrensningen, og da kan kongen scrape "så mye han vil" med script som han kjører i sin chrome client.
Men det kan også være at jeg må tenke om igjen?