Siguria

Autentikimi

Llogaritë menaxhohen nga Supabase Auth me email dhe fjalëkalim, Google OAuth ose GitHub OAuth. Pas hyrjes, shfletuesi juaj mban një token sesioni (një JWT) që rifreskohet automatikisht nga middleware-i i platformës, kështu që një sesion aktiv nuk skadon në heshtje në mes të punës.

API-ja e pranon atë token sesioni në dy forma: si cookie-ja e sesionit që paneli e dërgon gjithsesi, ose si një header Authorization Bearer. Qasja programore pa hyrje shfletuesi përdor çelësa API në vend të kësaj, të përshkruar më poshtë. Endpoint-et i refuzojnë kërkesat pa një kredencial të vlefshëm; vetëm rrugët shprehimisht publike, si kontrolli i shëndetit dhe formulari i kontaktit, funksionojnë pa autentikim.

Rolet dhe lejet

Çdo llogari ka saktësisht një rol: CLIENT, OPERATOR ose ADMIN. Klientët zotërojnë robotë dhe paguajnë për sesione, operatorët kontrollojnë robotë dhe fitojnë nga sesionet, dhe administratorët e drejtojnë platformën. Zgjidhni mes klient dhe operator gjatë onboarding-ut; roli admin caktohet nga administratorët e platformës dhe s'mund të zgjidhet vetë.

Kontrollet e rolit ndodhin në server për çdo kërkesë, jo në UI. Nën API, qasja në bazën e të dhënave kufizohet shtesë me politika row-level security, kështu që edhe një defekt në një endpoint nuk kthehet në qasje të lirë te rreshtat e llogarive të tjera.

Çelësat API

Çelësat API u japin skripteve dhe servera-ve qasje pa hyrje shfletuesi. I krijoni dhe i revokoni te /dashboard/settings; çelësat mbajnë prefiksin ayr_live_ dhe dërgohen si header Authorization Bearer. Një çelës vepron me rolin dhe lejet e llogarisë që e ka krijuar, kështu që një çelës i rrjedhur është pikërisht aq i keq sa një fjalëkalim i rrjedhur.

• Mbajini çelësat vetëm në server. Nuk u përket JavaScript-it në klient, aplikacioneve mobile, ose repozitorëve publikë.
• Përdorni një çelës për çdo integrim. Kur diçka rrjedh, doni të revokoni një konsumator, jo të gjithë.
• Rotojini pa ndërprerje: krijoni fillimisht çelësin zëvendësues, vendoseni në prodhim, pastaj revokoni të vjetrin te /dashboard/settings.
• Revokoni menjëherë në rast dyshimi. Krijimi i një çelësi të ri kushton sekonda; një sulmues me një çelës të vlefshëm mund të bëjë çdo gjë që mund të bëjë llogaria juaj.

Masat mbrojtëse gjatë kontrollit live

Kontrolli live është i lidhur me një qira sesioni. Një robot pranon komanda vetëm ndërkohë që është në saktësisht një sesion ACTIVE, dhe vetëm nga operatori që e mban atë sesion; vetë roboti shënohet IN_SESSION për të gjithë të tjerët. Një operator mund të mbajë më së shumti një sesion ACTIVE ose PAUSED njëherësh, gjë që përjashton mundësinë që një person të kontrollojë nominalisht dy krahë njëkohësisht.

Kokpiti ofron një ndalim emergjence që e ndalon krahun menjëherë, dhe pauzimi ose përfundimi i sesionit e ndalon rrjedhën e komandave në tërësi. Përveç kësaj, platforma monitoron aktivitetin e operatorit: pas një periudhe pa hyrje dërgohet një paralajmërim mosaktiviteti, dhe nëse operatori mbetet joaktiv, sesioni ndalon automatikisht. Kjo i mbron të dyja palët, klientin nga pagesa e kohës bosh dhe robotin nga qëndrimi në një gjendje të pakontrolluar me një qira aktive.

Gjurma e auditimit

Çdo sesion mban një regjistër ngjarjesh: fillim dhe përfundim, pauza dhe rifillime, kontrolle aktiviteti, paralajmërime mosaktiviteti, ndërrime operatorësh, kërkesa zgjatjeje dhe gabime, secila me vulë kohore. Kur shqyrtohet një mosmarrëveshje, ky regjistër ngjarjesh është dëshmia kryesore, gjë që është edhe një arsye pse platforma e shkruan automatikisht në vend që të mbështetet te kujtesa e dikujt.

Përtej sesioneve, veprimet e rëndësishme të platformës regjistrohen në një regjistër auditimi me id-në e përdoruesit që veproi, veprimin, burimin e prekur dhe metadata. Ndryshimet e profilit, transaksionet relevante për pagesat dhe veprimet e administratorëve lënë të gjitha shënime. Regjistrat e auditimit shkruhen nga platforma dhe s'janë të editueshëm përmes asnjë ndërfaqeje për përdoruesit.

Kriptimi dhe mbrojtja e të dhënave

I gjithë trafiku drejt dhe nga platforma është i kriptuar gjatë transportit me TLS, përfshirë transmetimet video dhe sinjalet e kontrollit. Në shtresën e të dhënave, politikat row-level security e kufizojnë qasjen në bazën e të dhënave sipas llogarisë. Të dhënat e pagesave janë kufiri më i qartë nga të gjithë: kartat dhe të dhënat bankare trajtohen ekskluzivisht nga Stripe dhe nuk prekin kurrë serverët e AY-Robots.

Raportimi i një dobësie

Nëse gjeni një problem sigurie, raportojeni me përgjegjshmëri përmes faqes /security ose formularit /contact duke përdorur kategorinë Bug Report. Përfshini çfarë keni gjetur, ku dhe si të riprodhohet; mos aksesoni të dhëna të përdoruesve të tjerë përtej minimumit të nevojshëm për të demonstruar problemin, dhe mos publikoni detaje para se të kemi pasur një rast të arsyeshëm ta rregullojmë. E lexojmë çdo raport.

Pyetje të shpeshta