சந்தாக்கள் இல்லாமலேயே இணையதளத்தின் நேரலை பார்வையாளர்களைக் கண்காணிக்கலாம்
ஒரு வாடிக்கையாளர் தனது இணையதளத்தில் யார் யார் நேரலையில் இருக்கிறார்கள் என்பதைத் தெரிந்துகொள்ள விரும்பினார்.
அவர்களுக்கு Tidio விட்ஜெட் (widget) பிடித்திருந்தது, ஆனால் அதற்காக சந்தா செலுத்த விரும்பவில்லை.
இதில் இரண்டு சவால்கள் இருந்தன:
- அந்தத் தளம் வெவ்வேறு ஹோஸ்டிங்கில் WordPress-ஐப் பயன்படுத்தியது.
- என்னால் Firebase-ஐ நேரடியாக WordPress அமைப்பில் சேர்க்க முடியவில்லை.
நான் Firebase பயன்படுத்தி ஒரு வெளிப்புறத் கண்காணிப்பானை (external tracker) உருவாக்கினேன். அது எவ்வாறு செயல்படுகிறது என்பதை இங்கே காணலாம்.
தீர்வு
நான் WordPress ஹெடரில் (header) ஒரு ஸ்கிரிப்ட் டேக் (script tag)-ஐப் பயன்படுத்தினேன். இந்த ஸ்கிரிப்ட் ஒரு தனிப்பட்ட Firebase திட்டத்துடன் இணைகிறது.
• நேரலை இருப்பு (Live Presence): நான் Firebase Realtime Database மற்றும் onDisconnect() செயல்பாட்டைப் பயன்படுத்தினேன். பயனர் தனது டேப்பை (tab) மூடிவிட்டாலோ அல்லது இணைப்பு துண்டிக்கப்பட்டாலோ, இது தானாகவே அவரை "online" பட்டியலிலிருந்து நீக்கிவிடும்.
• பார்வையாளர் வரலாறு (Visitor History): Firestore-இல் தரவுகளை எழுத நான் Netlify Function-ஐப் பயன்படுத்தினேன். இது சர்வர் பக்கத்தில் IP புவிசார் இருப்பிடத்தைக் (IP geolocation) கண்டறிய உதவுகிறது.
• பாதுகாப்பு (Security): நான் 익명 (anonymous) அங்கீகாரத்தைப் பயன்படுத்தினேன். பார்வையாளர்கள் தங்களின் சொந்த செஷன் நோடில் (session node) மட்டுமே தரவுகளை எழுத முடியும். நிர்வாகி (admin) மட்டுமே முழுப் பட்டியலையும் படிக்க முடியும்.
சிக்கலான பிழைகள்
இதை உருவாக்குவது எளிதாக இருக்கவில்லை. நான் மூன்று முக்கிய தொழில்நுட்பத் தடைகளைச் சந்தித்தேன்.
1. கேச்சிங் சிக்கல் (The Caching Trap)
வரலாறு பூஜ்ஜிய செஷன்களைக் காட்டியது. கண்காணிப்பு ஸ்கிரிப்ட் ஒரு வருட கேச் கொள்கையைக் (cache policy) கொண்டிருந்ததைக் கண்டறிந்தேன். பார்வையாளர்கள் ஸ்கிரிப்ட்டின் பழைய பதிப்பையே பயன்படுத்திக் கொண்டிருந்தனர்.
- தீர்வு: கண்காணிப்பு ஸ்கிரிப்ட்டிற்கு ஐந்து நிமிட கேச் கொள்கையை அமைத்தேன்.
2. போலி CORS பிழை (The Fake CORS Error)
பிரவுசர் ஒரு CORS பிழையைக் காட்டியது. எனக்கு டொமைன் ஒயிட்லிஸ்ட் (domain whitelist) சிக்கல் இருப்பதாக நினைத்தேன். ஒரு எளிய curl சோதனை சர்வர் சரியாகச் செயல்படுவதைக் காட்டியது.
உண்மை வேறாக இருந்தது. சர்வர் உண்மையில் செயலிழந்து (crashing) கொண்டிருந்தது.
Node.js-இல், நீங்கள் 204 ஸ்டேட்டஸ் குறியீட்டைப் பயன்படுத்தினால், பாடியாக (body) ஒரு காலியான சரத்தைப் (empty string) பயன்படுத்த முடியாது. நீங்கள் null என்பதைப் பயன்படுத்த வேண்டும். CORS ஹெடர்கள் அனுப்பப்படுவதற்கு முன்பே அந்த காலியான சரம் சர்வரை செயலிழக்கச் செய்தது. பிரவுசருக்கு எந்த ஹெடர்களும் கிடைக்காததால், அது ஒரு CORS பிரச்சனையாகக் கருதியது.
- தீர்வு: ரெஸ்பான்ஸ் பாடியை
''என்பதிலிருந்துnullஎன மாற்றினேன்.
3. விடுபட்ட தரவு இடைவெளி (The Missing Data Gap)
"இன்று" அல்லது "கடந்த 7 நாட்கள்" போன்ற வடிகட்டிகள் (filters) எதையும் காட்டவில்லை. சில பயனர்களின் இருப்பிடம் "Unknown" என்று காட்டப்பட்டது. நான் முதல்முறை பக்கம் லோட் ஆகும் போது மட்டுமே டைம்ஸ்டாம்ப் (timestamp) மற்றும் இருப்பிடத்தைக் கணக்கிட்டதால் இது நடந்தது. ஒரு பயனர் தனது பிரவுசரில் பழைய செஷனை வைத்திருந்தால், சர்வர் "start" நிகழ்வைத் தவறவிட்டிருக்கும்.
- தீர்வு: நான் கணக்கீட்டை idempotent ஆக மாற்றினேன். இப்போது ஒவ்வொரு நிகழ்வின் போதும் ஸ்கிரிப்ட் இந்த மதிப்புகளை மீண்டும் கணக்கிடுகிறது.
முக்கியக் குறிப்புகள்
• பிரவுசரில் வரும் CORS பிழை எப்போதும் ஒரு கான்ஃபிகரேஷன் (configuration) சிக்கல் மட்டுமல்ல. அது ஒரு சர்வர் செயலிழப்பை மறைக்கக்கூடும். எப்போதும் உங்கள் சர்வர் லாக்ஸ்களை (server logs) சரிபார்க்கவும்.
• ஒரு curl POST சோதனை பிரவுசரைச் சோதிப்பதில்லை. பிரவுசர்கள் முதலில் ஒரு OPTIONS preflight கோரிக்கையை அனுப்புகின்றன. உங்கள் சோதனை செல்லுபடியாக வேண்டுமென்றால், இதில் இதையும் சேர்க்க வேண்டும்.
• 204 போன்ற "no content" HTTP ஸ்டேட்டஸ்களுக்கு null என்பதைப் பயன்படுத்தவும். காலியான சரங்களைப் பயன்படுத்த வேண்டாம்.