सुरक्षा

प्रमाणीकरण

खाताहरू Supabase Auth ले इमेल र पासवर्ड, Google OAuth, वा GitHub OAuth ले व्यवस्थापन गर्छ। लगइनपछि, तपाईंको ब्राउजरले सत्र टोकन (एउटा JWT) राख्छ जुन प्लेटफर्म मिडलवेयरले स्वतः रिफ्रेस गर्छ, त्यसैले काम गरिरहेको सत्र काम गर्दागर्दै चुपचाप म्याद सकिँदैन।

API ले त्यो सत्र टोकनलाई दुई रूपमा स्वीकार्छ: ड्यासबोर्डले जे पनि पठाउने सत्र कुकीको रूपमा, वा Authorization Bearer हेडरको रूपमा। ब्राउजर लगइन बिनाको प्रोग्रामेटिक पहुँचले तलको वर्णन गरिएको API key प्रयोग गर्छ। इन्डपोइन्टहरूले मान्य क्रेडेन्सियल बिनाका अनुरोधहरू अस्वीकार गर्छन्; हेल्थ चेक र सम्पर्क फर्मजस्ता स्पष्ट रूपमा सार्वजनिक रुटहरूले मात्र प्रमाणीकरण बिना काम गर्छन्।

भूमिका र अनुमतिहरू

हरेक खातासँग ठ्याक्कै एउटा भूमिका हुन्छ: CLIENT, OPERATOR, वा ADMIN। क्लाइन्टहरूले रोबोटको स्वामित्व राख्छन् र सत्रका लागि तिर्छन्, अपरेटरहरूले रोबोट नियन्त्रण गर्छन् र सत्रबाट कमाउँछन्, र एडमिनहरूले प्लेटफर्म चलाउँछन्। तपाईं अनबोर्डिङको बेला client र operator बीच छान्नुहुन्छ; admin भूमिका प्लेटफर्म प्रशासकहरूले तोक्छन् र आफैं छनोट गर्न मिल्दैन।

भूमिका जाँच हरेक अनुरोधमा सर्भर-साइडमा हुन्छ, UI मा होइन। API भन्दा तल, डेटाबेस पहुँच थप रूपमा row-level security नीतिहरूले सीमित हुन्छ, त्यसैले इन्डपोइन्टको कुनै बगले पनि अरू खाताका पङ्क्तिहरूमा नि:शुल्क पहुँचमा बदलिँदैन।

API key हरू

API key ले स्क्रिप्ट र सर्भरलाई ब्राउजर लगइन बिना पहुँच दिन्छ। तपाईं तिनलाई /dashboard/settings मा बनाउनुहुन्छ र रद्द गर्नुहुन्छ; key हरूमा ayr_live_ प्रिफिक्स हुन्छ र Authorization Bearer हेडरको रूपमा पठाइन्छन्। एउटा key ले यसलाई बनाउने खाताकै भूमिका र अनुमतिसाथ काम गर्छ, त्यसैले चुहिएको key ठ्याक्कै चुहिएको पासवर्डजत्तिकै खराब हुन्छ।

• Key हरू सर्भर-साइडमा राख्नुहोस्। ती क्लाइन्ट-साइड JavaScript, मोबाइल एप, वा सार्वजनिक रिपोजिटरीमा नबसुन्।
• प्रति इन्टिग्रेसन एउटा key प्रयोग गर्नुहोस्। केही चुहियो भने, तपाईंले सबैलाई होइन, एउटा उपभोक्तालाई मात्र रद्द गर्न चाहनुहुन्छ।
• डाउनटाइम बिना घुमाउनुहोस्: पहिले प्रतिस्थापन key बनाउनुहोस्, डिप्लोय गर्नुहोस्, अनि /dashboard/settings मा पुरानो key रद्द गर्नुहोस्।
• कुनै पनि शङ्का लाग्नासाथ तुरुन्तै रद्द गर्नुहोस्। नयाँ key बनाउन केही सेकेन्ड मात्र लाग्छ; मान्य key भएको आक्रमणकारीले तपाईंको खाताले जे गर्न सक्छ त्यो सबै गर्न सक्छ।

लाइभ नियन्त्रणको बेला सुरक्षा उपाय

लाइभ नियन्त्रण सत्र लिजसँग बाँधिएको हुन्छ। रोबोटले ठ्याक्कै एउटा ACTIVE सत्रमा रहँदा मात्र, र त्यो सत्र राख्ने अपरेटरबाट मात्र आदेश स्वीकार्छ; रोबोट आफैं अरू सबैका लागि IN_SESSION भनी चिन्ह लगाइएको हुन्छ। एउटा अपरेटरले एकैचोटि बढीमा एउटा ACTIVE वा PAUSED सत्र राख्न सक्छन्, जसले एउटै व्यक्तिले नाममा एकैचोटि दुई आर्म नियन्त्रण गर्ने कुरा हटाउँछ।

ककपिटले आर्मलाई तुरुन्तै रोक्ने इमर्जेन्सी स्टप दिन्छ, र सत्र रोक्दा वा सक्याउँदा समग्र आदेश प्रवाह रोकिन्छ। त्यसमाथि, प्लेटफर्मले अपरेटरको गतिविधि अनुगमन गर्छ: इनपुट नभएको समयपछि निष्क्रियता चेतावनी पठाइन्छ, र अपरेटर निष्क्रिय नै रहे सत्र स्वतः रोकिन्छ। यसले दुवैतिर सुरक्षा दिन्छ, क्लाइन्टलाई खाली समयको तिर्नुबाट र रोबोटलाई लाइभ लिजसहित अनियन्त्रित अवस्थामा बस्नुबाट।

अडिट ट्रेल

हरेक सत्रले एउटा इभेन्ट लग राख्छ: सुरु र अन्त्य, रोक र फेरि सुरु, गतिविधि जाँच, निष्क्रियता चेतावनी, अपरेटर स्विच, विस्तार अनुरोध, र त्रुटिहरू, हरेकमा समयचिह्नसहित। विवाद समीक्षा हुँदा, यो इभेन्ट लग नै मुख्य प्रमाण हो, जुन प्लेटफर्मले यसलाई कसैको सम्झनामा भर पर्नुको साटो स्वतः लेख्नुको अर्को कारण हो।

सत्रबाहेक, महत्त्वपूर्ण प्लेटफर्म कार्यहरू कार्य गर्ने प्रयोगकर्ता id, कार्य, प्रभावित स्रोत, र मेटाडेटासहित अडिट लगमा रेकर्ड गरिन्छ। प्रोफाइल परिवर्तन, भुक्तानी-सम्बन्धित लेनदेन, र एडमिन कार्यहरूले सबैले प्रविष्टि छोड्छन्। अडिट रेकर्डहरू प्लेटफर्मले लेख्छ र कुनै प्रयोगकर्ता-सामना गर्ने इन्टरफेसमार्फत सम्पादन गर्न मिल्दैन।

इन्क्रिप्सन र डेटा सुरक्षा

प्लेटफर्मबाट र प्रति सबै ट्राफिक TLS ले ट्रान्जिटमा इन्क्रिप्ट गरिन्छ, भिडियो स्ट्रिम र नियन्त्रण सिग्नल सहित। डेटा लेयरमा, row-level security नीतिहरूले प्रति खाता डेटाबेस पहुँच सीमित गर्छन्। भुक्तानी डेटा सबैभन्दा स्पष्ट सीमा हो: कार्ड र बैंक विवरण पूर्णतः Stripe ले सम्हाल्छ र कहिल्यै AY-Robots सर्भरलाई छुँदैन।

कमजोरी रिपोर्ट गर्दै

तपाईंले कुनै सुरक्षा समस्या फेला पार्नुभयो भने, /security पृष्ठ वा Bug Report श्रेणी प्रयोग गरेर /contact फर्ममार्फत जिम्मेवारीपूर्वक रिपोर्ट गर्नुहोस्। तपाईंले के फेला पार्नुभयो, कहाँ, र यसलाई कसरी पुनरुत्पादन गर्ने भन्ने समावेश गर्नुहोस्; समस्या देखाउन आवश्यक न्यूनतमभन्दा बढी अरू प्रयोगकर्ताको डेटा पहुँच नगर्नुहोस्, र हामीले ठीक गर्ने उचित मौका नपाउँदै विवरण प्रकाशित नगर्नुहोस्। हामी हरेक रिपोर्ट पढ्छौं।

बारम्बार सोधिने प्रश्नहरू