clk PAYMENT PROOF LEGIT URL Shortener kuidas teenida internetis tasuta raha mai 2020 INDIA!

Umbes aasta tagasi vahetasime oma saidi HTTP-lt HTTPS-ile.

Meil on staatiline veebisait, millel pole kasutaja sisendi funktsionaalsust, nii et me ei pidanud seda tingimata HTTPS-i vahetamiseks varem vajalikuks, põhjuseks, miks me muutusime, on see, et me kasutasime mõned aastad tagasi palju Google Analyticsi viiteandmeid Google Analytics, kuid märkasime, et üha rohkem liiklust on loetletud otsese liiklusena, eeldasime, et see oli tingitud asjaolust, et saidid, kus meie liikluse suunamisel olid ka HTTPS-i üle läinud.

Alates muudatusest EI OLE Google Analyticsi suunamisandmete taastamist jätkunud.

Huvitav, kas see on tingitud sellest, et mõni vanem lingid meie veebisaidile on pigem HTTP kui HTTPS versioon, kuigi me oleme nende vahel 301.

Kas see oleks nii ja kui on, siis kas saaksime selle siiski parandada, et saada rohkem suunamisandmeid?

  • 1 Huvitav küsimus. Ainus võimalus, mis pähe tuleb, on HSTS-i juurutamine ja saidi jõudmine eellaadimisloendisse. See sunniks HTTPS-i nii, et enamik kasutajaid ei satuks kunagi HTTP-saidile, isegi kui nad sellele lingi leiaksid. Ma pole kindel, kas see aitaks suunajaandmetest või mitte. Võib-olla on kellelgi siin kogemusi.
  • Tänan, et mõtlesin sellele veel, kas peaksin nägema soovitajate andmeid serveri logifailides? (ma pole nendega eriti tuttav) Olen tutvunud algandmete failiga ja iga päringu jaoks näen vaid taotlevat IP-d, päringu HTTP-olekukoodi ja taotletavat ressurssi. Oleksin siiski leidnud, et peamine probleem oli üsna tavaline, kuna enamus 5-aastaseid saite ei olnud HTTPS-i, nii et neil oleks oma saidile linke HTTP-versioonile, mitte HTTPS-i versioonile
  • "ilma kasutaja sisendi funktsioonideta", pole see ainus põhjus, miks HTTPS-i kasutada. Mõlemad suunad peavad olema kaitstud: mida kasutajad teile saadavad (krediitkaardinumbrid jne), aga ka seda, mida teie kasutajatele saadate. Teie sait võib olla staatiline, kuid see võib anda teavet, mis vajab autentimist, veendudes, et see pärineb tõesti teie käest ja et seda pole transiidi käigus muudetud. Need kaks funktsiooni (autentimine ja konfidentsiaalsus / terviklikkus) on need, mida HTTPS teile pakub.
+25

Testisin just, kas HSTS-i juurutamine ja saidi eellaadimisloendisse viimine võimaldaks brauseritel suunaja suunata http link teie saidile. Kahjuks see ei toimi.

Testi sooritasin järgmiselt:

  1. Leidsin a .dev sait PHP-skriptiga, mis kajab viitaja tagasi. Ma tegin seda Google'ist otsides site:.dev HTTP_REFERER. Kuna kogu .dev ülataseme domeen on HSTS-i eellaadimisloendis, ükskõik milline .dev sait skriptiga, mis näitab HTTP muutujaid, töötab testimiseks.
  2. Lõin oma dokumendi https sait, millel on kaks linki, mis osutavad saidile .dev mannekeeni parameetriga sait, et klõpsude vahel vahemälu ei toimuks:

    HTTPS link
    HTTP link
  3. Avasin oma brauseris lehe ja klõpsasin kahel lingil.

Nii Firefox kui ka Chrome käitusid samamoodi. Nad edastasid viitaja HTTPS-lingil, kuid mitte HTTP-lingil. Ma lootsin, et kuna HSTS ajakohastab HTTP automaatselt HTTPS-i, ilma et teie server üle jõuaks, värskendataks ka viitajate eeskirju automaatselt. Ei olnud.

Kuna HSTS ei aita, oleks ainus viis, mida ma oma viiteandmete taastamiseks tean, võtta ühendust kõigi saitidega ja paluda neil oma saite muuta. Nad võivad kas muuta saidi lingid saidile https või muuta neid Referrer-Policy päis unsafe-url.

Väline HTTPS-sait peaks ka teie HTTPS-i saidi linkimiseks värskendama tagasilinki, vastasel juhul, kui link ise on endiselt HTTP, siis Referer päist ei saadetud. Vanu tagasilinke pole ilmselt värskendatud.

See pole midagi pistmist teie HTTP-st HTTPS-i ümbersuunamisega - see muidu läheks üle Referer (ikka kasutajaagendist sõltuv). Probleem on selles, et Referer esialgses taotluses tõenäoliselt ei saadeta.

HSTS + eellaadimisloend (nagu kommentaarides mainitud) mai selles osas abi peaks -. - käskige brauseril esialgset taotlust uuendada (nagu oleks tagasilink juba olnud HTTPS) ja lubaks seega Referer saadetakse. Ainult HSTS-ist ei pruugi piisata, välja arvatud juhul, kui teil on palju korduvaid kasutajaid, kes järgivad tagasilinke. Kuna brauser "mäletab" HSTS-i (ilma eelsalvestusloendis olekuta) alles pärast seda, kui kasutaja teie HTTPS-i saiti esimest korda külastab. MUUDA: @ Stepheni testimisest tundub siiski, et see ei aita lõppude lõpuks!

Pange tähele ka seda, et veebilehtedel on tänapäeval palju suurem kontroll Referer mis saadetakse, kui nad viitajate eeskirju rakendavad. See võimaldab saitidel selle lihtsalt blokeerida Referer kõigi väljaminevate taotluste korral, kui nad seda soovivad.

Nüüd, kui teie saiti on värskendatud HTTPS-iga, pöörduksin tagasi viitavate saitide juurde ja paluksin linki värskendada aadressile https (mitte täielik parandus, vaid õige aluse seadmine).

Teine tegur, mida tuleb arvestada, on see, kas teie saiti ja viidavaid saite võidakse karistada HTTPS-i puudumise eest. Olen aru saanud (ridade vahelt lugedes), et Google ei premeeri turvamata saite, olenemata sellest, kas kasutajad edastavad konfidentsiaalset teavet või mitte. Kas saidid, mis teile liiklust saatsid, on samal perioodil liikluse vähenenud? st kas YoY saatmiseks on lihtsalt vähem kasutajaid?

Pidage meeles, et kasutajad jõuavad enne turvavaba saidile pääsemist lehele „SITE UNSECURE - PÖÖRDA”.

Küsin, sest kui teie suunamisliiklus on maas, võib see olla rohkem seotud teie liiklust suunava saidiga kui teie enda oma, eriti kui need saidid ei taganud ennast.

Minu suurim nõuanne on siiski see, et Google pöördub minu kogemuste järgi harva tagasi, ma ei keskenduks liiga palju vana suunamisliikluse taastamisele. Pigem paranduste tegemine, mis võivad selle põhjustada, parandab teie turvalisust ja kasutajasignaale, et järgmisel uptickil oleks kasu.

  • Näib, et teie vastus näitab, et see on teie arvates Google'i edetabeliprobleem. Ei ole. Andmete hankimisel Google Analyticsi on probleem.
  • @StephenOstermiller Vist peaks olema täpsustus, mulle ei tundu, et ta ütleks, et andmeid ennast ei täideta, kuid et temaga linkivate saitide suunamisliiklus on vähenenud (ta eeldab HTTPS-i tõttu) ja see pole veel toibus pärast oma saidi kindlustamist. Sel juhul tekib küsimus, kuidas kaotatud suunamisliiklust "uuesti kinni püüda", minu teooria järgi saab kindlaks teha, kas tegemist on viitava allika probleemiga.
  • Kinnituseks ei tähenda see, et liiklus oleks vähenenud, vaid näib, et see on suunamisliiklusest GA-sse sisenenud "otseseks" liikluseks.
  • Ma näen, aitäh selgituste eest. Sellisel juhul, kui viidavad saidid kolisid HTTPS-i ajal, kui olite HTTP-ga, siis esitati andmed otse. Turvalised veebisaidid, mis viitavad mitteturvalistele veebisaitidele, ei saada suunamisandmeid. Teiseks veenduge, et kasutajad pääseksid juurde ainult teie saidi HTTP-versioonile, nii et te ei kaotaks viitamisliiklust.

none: Charles Robertson | none

none