Retumilo raportas Europe/London dum IP-datumbazo lokas la peton en America/New_York. Tio estas malkongruo inter du observoj, kaj indas registri ĝin. Ĝi ne estas pruvo, ke la vizitanto uzas VPN, kaj ĝuste trakti ĝin kiel pruvon estas la loko, kie plej multaj efektivigoj eraras. La komparo sube tenas la du valorojn, kaj iliajn fiaskmanierojn, aparte.

Du observoj kun malsamaj posedantoj

La retumila valoro estas agordo: la zono, kiun la operaciumo aŭ la uzanto elektis por formatigi datojn. La datumbaza valoro estas takso ligita al IP-reto, produktita de provizanto, kiu mapas adresblokojn al lokoj. Neniu el ili estas aŭtentigita aserto pri tio, kie la vizitanto staras, kaj neniu scias, kiun retan vojon la peto prenis.

Ĉar la posedantoj malsamas, la du valoroj povas malkongrui pro kialoj tute sen rilato al privatecaj iloj. Vojaĝanto, kiu konservas la hejman zonon, firmaa tekkomputilo fiksita al la tempo de la sidejo, satelita ligilo kun regiona eliro, aŭ malnova vico en la datumbazo ĉiuj produktas malkongruon.

Kiel ĉiu valoro fakte produktiĝas

Retumilo povas legi sian solvitan zonon per new Intl.DateTimeFormat().resolvedOptions().timeZone, kio redonas IANA-identigilon derivitan de la agordoj de la formatilo. Ĝi ne petas permeson pri loko kaj ne konsultas GPS. Sur la servilo, determinu la klientan adreson el via fidinda prokura agordo, poste serĉu ĝin ĉe aprobita provizanto. Plusenda kaplinio liverita de la vizitanto ne estas aŭtomate tiu adreso.

Konservu la du observojn en apartaj kampoj kune kun la observa tempo kaj la serĉa rezulto. Nomigi la derivitan kampon vpnDetected dum la kalkulo estas nur zona komparo enbakas konkludon en mezuron kaj malfaciligas postan revizion.

Kion kongruo kaj malkongruo ĉiu pruvas

ObservoKio restas nesolvita
Malsamaj raportitaj zonojVojaĝo, konservita agordo, komerca enirejo, prokurilo aŭ datumbaza eraro povas ĉiuj produkti ĝin.
La sama raportita zonoVPN-eliro povas situi en la zono de la uzanto, do kongruo ne pruvas rektan konekton.
Unu valoro mankas aŭ estas nevalidaLa komparo ne disponeblas, kio estas nek kongruo nek malkongruo.

La nesimetrio gravas pli ol la tabelo sugestas. Malkongruo havas multajn senkulpajn klarigojn, dum kongruo havas almenaŭ unu kulpan, do neniu direkto subtenas kategorian regulon. La propraj preciznotoj de la provizanto priskribas limigitan precizecon kaj mankantajn datumojn, kaj atentigas, ke anonimiga servo povas malkaŝi la lokon de sia servilo anstataŭ tiun de la uzanto.

Tial la signalo apartenas al riska poentaro kun registrita kialo kaj eksplicita nekonata stato, ne al bulea valoro, kiu regas aliron.

UTC-deŝovoj ne estas fuŝsolvo

Kompari deŝovojn anstataŭ zonajn identigilojn ne riparas la konkludon. Du malsamaj zonoj povas dividi deŝovon dum parto de la jaro, kaj la sama zono povas ŝanĝi deŝovon ĉe somertempa limo. Se funkcio vere bezonas deŝovon por planado, kalkulu ĝin por la konkreta momento anstataŭ konservi unu nombron kaj reuzi ĝin kiel identecan pruvon.

Ĉena komparo havas sian propran kaptilon: du literumoj de la sama zono, aŭ malnova alinomo, malsamos kiel teksto dum ili priskribas la saman agordon. Validigu la identigilojn kaj komparu per la horzona traktado de la platformo anstataŭ kongruigi krudajn ĉenojn.

Bloki aŭ poenti: elektu la respondon konscie

Por tempo-montrado, demandu la vizitanton, kiun zonon li preferas, kaj haltu tie. Por aplikaĵa riska sistemo, traktu malkongruon kiel unu malfortan kuntekstan signalon apud pruvoj, kiuj taŭgas por la reala minacmodelo, kaj lasu malsukcesan serĉon produkti nekonaton anstataŭ silentan detekton. Bloki nur pro la komparo transformas mezuran breĉon en akuzon al la uzanto.

Se sekvohava decido bezonas pli fortan garantion, uzu kontrolan aŭ aŭtentigan paŝon destinatan por tio. Horzona heŭristiko ne povas doni tian garantion, kaj detektilo, kiu kalkulas mankantajn pruvojn kiel sukceson, povas ŝajni efika dum ĝi respondas al malsama demando ol tiu, kiun vi starigis.

Rilataj artikoloj