VPN സർവർ മാറ്റിയാൽ നിങ്ങൾ കടയിൽ നിന്ന് ലോഗ് ഔട്ട് ആകുമോ?
പുതിയ എക്സിറ്റ് വിലാസം കുക്കി ജാർ കാലിയാക്കില്ല. ആദ്യം നിങ്ങൾ നെറ്റ്‌വർക്ക് പാതയാണോ, ലോഗിൻ ചെയ്ത സെഷനാണോ, സംഭരിച്ച സൈറ്റ് ഡാറ്റയാണോ പരിശോധിക്കുന്നതെന്ന് തീരുമാനിക്കുക.
മറ്റൊരു ടാബിൽ കട തുറന്നിരിക്കുമ്പോൾ VPN എക്സിറ്റ് മാറ്റുക, കൂട സാധാരണയായി അവിടെത്തന്നെ ഉണ്ടാകും. ഇത് VPN-ന്റെ തകരാറല്ല; ബ്രൗസർ പറഞ്ഞത് കൃത്യമായി ചെയ്യുകയാണ്. കുക്കി ബ്രൗസർ അയയ്ക്കുന്നു, പുതിയ നെറ്റ്‌വർക്ക് പാത ബ്രൗസർ സംഭരിക്കുന്നത് മാറ്റുന്നില്ല. «സൈറ്റ് ഇപ്പോഴും എന്നെ അറിയുന്നു» എന്ന വാക്യത്തിന് പിന്നിൽ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങളുണ്ട്, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏതാണ് ചോദിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ചിരിക്കും ഉത്തരം.
മൂന്ന് ചോദ്യങ്ങൾ, ഒരു ലക്ഷണം
ആദ്യം: സൈറ്റ് സംഭരിച്ച കുക്കി തിരിച്ചറിയുന്നുണ്ടോ? രണ്ടാമത്: ഏതെങ്കിലും ഒരു കുക്കിയിൽ നിന്ന് സ്വതന്ത്രമായി നിലനിൽക്കുന്ന ലോഗിൻ ചെയ്ത അക്കൗണ്ട് തിരിച്ചറിയുന്നുണ്ടോ? മൂന്നാമത്: സംഭരിച്ച അവസ്ഥയല്ല, ബ്രൗസറിനെയോ ഉപകരണത്തെയോ കുറിച്ചുള്ള എന്തെങ്കിലും തിരിച്ചറിയുന്നുണ്ടോ? ഓരോന്നിനും അതിന്റേതായ പരിശോധനയും പരിഹാരവുമുണ്ട്.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
ഏറ്റവും സാധാരണമായ ആശയക്കുഴപ്പം ആദ്യത്തേത് മാറ്റി രണ്ടാമത്തേത് പിന്തുടരുമെന്ന് പ്രതീക്ഷിക്കുന്നതിൽ നിന്ന് വരുന്നു. നെറ്റ്‌വർക്ക് വിലാസവും ബ്രൗസർ സ്റ്റോറും രണ്ട് വേറിട്ട സംവിധാനങ്ങളാണ്, ഒരേ പേജ് യാദൃച്ഛികമായി അവ രണ്ടും ഉപയോഗിക്കുന്നു.
കുക്കി യഥാർത്ഥത്തിൽ എന്താണ് വഹിക്കുന്നത്
RFC 6265-ൽ വ്യക്തമാക്കിയ HTTP അവസ്ഥാ നിർവഹണം ബോധപൂർവം ലളിതമാണ്: സർവർ ഒരു പരിധിയോടെ പേരും മൂല്യവും സജ്ജമാക്കുന്നു, ആ പരിധിയുമായി പൊരുത്തപ്പെടുന്ന അഭ്യർത്ഥനകൾക്ക് ബ്രൗസർ അവ തിരികെ നൽകുന്നു. മൂല്യം ഒരു സെഷൻ ഐഡന്റിഫയർ, മുൻഗണന, അല്ലെങ്കിൽ സർവർ കൂടയുടെ റെക്കോർഡുമായി ബന്ധിപ്പിക്കുന്ന അതാര്യ ടോക്കൺ ആകാം. ഈ സംവിധാനത്തിൽ എവിടെയും ക്ലയന്റിന്റെ വിലാസം പരാമർശിക്കുന്നില്ല.
ഈ രൂപകൽപ്പനയാണ് സാധാരണ ലോഗിനുകളും കൂടകളും നെറ്റ്‌വർക്ക് മാറ്റത്തെ അതിജീവിക്കുന്നതിന്റെ കാരണം, ട്രാക്കറുകൾക്കും അവ അതിജീവിക്കുന്നതിന്റെ കാരണവും ഇതുതന്നെ. ഒരേ സംവിധാനം രണ്ട് ലക്ഷ്യങ്ങൾക്കും സേവിക്കുന്നു, അവ തമ്മിൽ വേർതിരിക്കുന്നുമില്ല. പ്രോട്ടോക്കോളിൽ ക്ലയന്റിന്റെ വിലാസത്തിന് ഫീൽഡില്ല, അതിനാൽ പുതിയ എക്സിറ്റിന് അസാധുവാക്കാൻ ഒന്നുമില്ല. കുക്കിയെ നെറ്റ്‌വർക്ക് ഉത്ഭവവുമായി ബന്ധിപ്പിക്കാൻ ആഗ്രഹിക്കുന്ന സൈറ്റ് ആ യുക്തി സ്വയം ചേർക്കേണ്ടിവരും.
ഒരു സൈറ്റ് കുക്കി തിരികെ നൽകുമ്പോൾ, ആ മൂല്യം ചൂണ്ടിക്കാണിക്കുന്ന റെക്കോർഡ് സർവർ തിരയുന്നു. അഭ്യർത്ഥന സഞ്ചരിച്ച പാത മാറ്റുന്നത് ആ തിരയലിനെ മാറ്റുന്നില്ല, ഷോപ്പിംഗ് കൂടയുടെ നിരീക്ഷണത്തിന്റെ മുഴുവൻ വിശദീകരണവും അതാണ്.
നിങ്ങളുടെ പരിശോധന എന്താണ് അളക്കുന്നതെന്ന് തീരുമാനിക്കുക
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് നിങ്ങൾ ആരംഭിക്കുന്ന അവസ്ഥ എഴുതിവയ്ക്കുക: ഏത് ബ്രൗസർ പ്രൊഫൈൽ, ഏത് അക്കൗണ്ട്, ഏത് സൈറ്റ് ഡാറ്റ, ഏത് നെറ്റ്‌വർക്ക് പാത. തുടർന്ന് അവയിൽ കൃത്യമായി ഒന്ന് മാറ്റി നിരീക്ഷിക്കുക. എക്സിറ്റ് വിലാസവും ബ്രൗസർ പ്രൊഫൈലും ഒരുമിച്ച് മാറ്റുന്ന പരിശോധന അവയിൽ ഏതിനെക്കുറിച്ചും ഒന്നും തെളിയിക്കുന്നില്ല.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartരണ്ട് കമാൻഡുകളും ഒരേ കുക്കി ഫയൽ വീണ്ടും ഉപയോഗിക്കുന്നു, രണ്ടാമത്തേത് ഹോസ്റ്റ് അനുവദിക്കുന്നിടത്ത് വ്യത്യസ്ത പ്രാദേശിക സ്രോതസ്സ് വിലാസം നിർബന്ധിക്കുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും കൂടയുടെ പ്രതികരണം ഒന്നുതന്നെ, കാരണം സർവർ ഒരിക്കലും വ്യത്യസ്ത ക്ലയന്റ് ഐഡന്റിറ്റി കണ്ടിട്ടില്ല, വ്യത്യസ്ത പാത മാത്രം കണ്ടു. ആവർത്തിക്കാവുന്ന ഒരു ജോടി അഭ്യർത്ഥനകളിൽ ഇതാണ് സംവിധാനം.
സംഭരിച്ച അവസ്ഥയില്ലാതെ സൈറ്റ് നിങ്ങളെ തിരിച്ചറിയുന്നുണ്ടോ എന്ന് കാണുകയാണ് ലക്ഷ്യമെങ്കിൽ, ആ സൈറ്റിന്റെ ഡാറ്റ മായ്ച്ച് ആവർത്തിക്കുക. ഇപ്പോഴും തിരിച്ചറിയുന്നുവെങ്കിൽ, അടുത്ത സംശയിക്കുന്നവർ കുക്കിയല്ല, ലോഗിൻ ചെയ്ത അക്കൗണ്ട്, നിങ്ങൾ പിന്തുടർന്ന ലിങ്ക്, അല്ലെങ്കിൽ ബ്രൗസർ സ്വഭാവങ്ങൾ എന്നിവയാണ്.
ശരിയായ അവസ്ഥ മായ്ക്കുക, നെറ്റ്‌വർക്കല്ല
ഒരു സൈറ്റിന്റെ സ്റ്റോറേജ് നീക്കം ചെയ്യുന്നത് ബ്രൗസറിന്റെ സ്വന്തം നിയന്ത്രണങ്ങളുടെ പരിധിയിൽ വരുന്നു, പലപ്പോഴും പാർശ്വഫലമായി നിങ്ങളെ ലോഗ് ഔട്ട് ചെയ്യുകയോ മുൻഗണനകൾ പുനഃസജ്ജമാക്കുകയോ ചെയ്യും. അത് അക്കൗണ്ടോ സേവനം ഇതിനകം സൂക്ഷിക്കുന്ന റെക്കോർഡുകളോ ഇല്ലാതാക്കുന്നില്ല; അവയ്ക്ക് സേവനത്തിന്റെ സ്വന്തം നടപടിക്രമം വേണം.
ക്രോസ്-സൈറ്റ് നിയന്ത്രണങ്ങൾ പ്രശ്നത്തിന്റെ മറ്റൊരു ഭാഗം കൈകാര്യം ചെയ്യുന്നു. എംബെഡ് ചെയ്ത സേവനങ്ങൾ സൈറ്റുകൾക്കിടയിൽ പങ്കിട്ടേക്കാവുന്ന സ്റ്റോറേജ് ബ്രൗസറുകൾ തടയുകയോ വിഭജിക്കുകയോ ചെയ്യാം, അതേസമയം ഒന്നാം-കക്ഷി ലോഗിൻ പ്രവർത്തിക്കുന്നത് തുടരുന്നു. അതിനാൽ വിജയകരമായ ലോഗിൻ ക്രോസ്-സൈറ്റ് ട്രാക്കിംഗ് പ്രവർത്തിക്കുന്നു എന്നതിന്റെ തെളിവല്ല.
സ്വകാര്യ വിൻഡോകൾ ആളുകൾ പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയ പരിധിയുള്ള മറ്റൊരു ഉപകരണമാണ്. സെഷനിടയിൽ സൈറ്റുകൾക്ക് ഇപ്പോഴും കുക്കി സജ്ജമാക്കാം, ലോഗിൻ ഇപ്പോഴും അക്കൗണ്ട് തിരിച്ചറിയുന്നു. താൽക്കാലിക അവസ്ഥ ഉപേക്ഷിക്കുന്നത് സ്വകാര്യ സെഷൻ അവസാനിപ്പിക്കുന്നതാണ്, അതായത് ഒരു ടാബല്ല, എല്ലാ സ്വകാര്യ വിൻഡോകളും അടയ്ക്കണം.
അവസാനമായി, ഫിംഗർപ്രിന്റിംഗ് വഴിയുള്ള തിരിച്ചറിയലിനെ ആദ്യ വിശദീകരണമല്ല, ഒരു സാധ്യതയായി കാണുക. ഉപകരണത്തിന്റെയും ബ്രൗസറിന്റെയും സ്വഭാവങ്ങൾ സംഭരിച്ച കുക്കിയില്ലാതെ സന്ദർശനങ്ങൾ ബന്ധിപ്പിക്കാം, സ്റ്റോറേജ് മായ്ക്കുന്നത് അവയെ ബാധിക്കില്ല. ആദ്യം ലളിതമായ കാരണങ്ങൾ പരിശോധിക്കുക, പിന്നീട് അന്വേഷണം വിപുലീകരിക്കുക, അടുത്ത താരതമ്യം അർത്ഥവത്താകാൻ ഏത് അവസ്ഥ മാറ്റിയെന്ന് കുറിച്ചുവയ്ക്കുക.