Säkerhet

Autentisering

Konton hanteras av Supabase Auth med e-post och lösenord, Google OAuth eller GitHub OAuth. Efter inloggning håller din webbläsare en sessionstoken (en JWT) som förnyas automatiskt av plattformens middleware, så en fungerande session löper inte tyst ut mitt i arbetet.

API:et accepterar den sessionstoken i två former: som sessionscookien instrumentpanelen ändå skickar, eller som en Authorization Bearer-header. Programmatisk åtkomst utan webbläsarinloggning använder API-nycklar i stället, beskrivet nedan. Slutpunkter avvisar förfrågningar utan giltiga autentiseringsuppgifter; bara de uttryckligen publika rutterna, som hälsokontrollen och kontaktformuläret, fungerar oautentiserat.

Roller och behörigheter

Varje konto har exakt en roll: CLIENT, OPERATOR eller ADMIN. Kunder äger robotar och betalar för sessioner, operatörer styr robotar och tjänar på sessioner, och administratörer driver plattformen. Du väljer mellan kund och operatör under onboardingen; adminrollen tilldelas av plattformens administratörer och kan inte väljas själv.

Rollkontroller sker serversidan vid varje förfrågan, inte i gränssnittet. Under API:et är databasåtkomst dessutom begränsad med row-level security-policyer, så även en bugg i en slutpunkt förvandlas inte till fri åtkomst till andra kontons rader.

API-nycklar

API-nycklar ger skript och servrar åtkomst utan webbläsarinloggning. Du skapar och återkallar dem i /dashboard/settings; nycklar bär prefixet ayr_live_ och skickas som en Authorization Bearer-header. En nyckel agerar med rollen och behörigheterna för kontot som skapade den, så en läckt nyckel är exakt lika illa som ett läckt lösenord.

• Håll nycklar serversidan. De hör inte hemma i klientsidans JavaScript, mobilappar eller publika repositories.
• Använd en nyckel per integration. Läcker något vill du kunna återkalla en konsument, inte alla.
• Rotera utan driftstopp: skapa ersättningsnyckeln först, driftsätt den, återkalla sedan den gamla nyckeln i /dashboard/settings.
• Återkalla omedelbart vid minsta misstanke. Att skapa en ny nyckel tar sekunder; en angripare med en giltig nyckel kan göra allt ditt konto kan.

Skydd under live-styrning

Live-styrning är bunden till en sessionslease. En robot accepterar kommandon bara medan den är i exakt en ACTIVE session, och bara från operatören som håller den sessionen; roboten själv markeras IN_SESSION för alla andra. En operatör kan hålla högst en ACTIVE eller PAUSED session åt gången, vilket utesluter att en person nominellt styr två armar samtidigt.

Cockpiten har ett nödstopp som omedelbart stoppar armen, och att pausa eller avsluta sessionen stoppar kommandoflödet som helhet. Utöver det övervakar plattformen operatörens aktivitet: efter en period utan inmatning skickas en inaktivitetsvarning, och förblir operatören inaktiv stoppas sessionen automatiskt. Det skyddar båda sidor, kunden från att betala för stillastående tid och roboten från att sitta i ett okontrollerat tillstånd med en aktiv lease.

Granskningsspår

Varje session håller en händelselogg: start och slut, pauser och återupptaganden, aktivitetskontroller, inaktivitetsvarningar, operatörsbyten, förlängningsbegäranden och fel, var och en med en tidsstämpel. När en tvist granskas är den här händelseloggen huvudbeviset, vilket är ytterligare en anledning till att plattformen skriver den automatiskt i stället för att förlita sig på någons minne.

Utöver sessioner registreras betydande plattformsåtgärder i en granskningslogg med det agerande användar-id:t, åtgärden, den påverkade resursen och metadata. Profiländringar, betalningsrelevanta transaktioner och adminåtgärder lämnar alla poster. Granskningsposter skrivs av plattformen och går inte att redigera genom något användargränssnitt.

Kryptering och dataskydd

All trafik till och från plattformen krypteras under överföring med TLS, inklusive videoströmmar och styrsignaler. På datalagret begränsar row-level security-policyer databasåtkomst per konto. Betalningsdata är den tydligaste gränsen av alla: kort och bankuppgifter hanteras uteslutande av Stripe och rör aldrig AY-Robots servrar.

Rapportera en sårbarhet

Hittar du ett säkerhetsproblem, rapportera det ansvarsfullt genom sidan /security eller formuläret /contact med kategorin Bug Report. Inkludera vad du hittade, var, och hur man återskapar det; kom inte åt andra användares data utöver minimum som behövs för att visa problemet, och publicera inte detaljer innan vi haft en rimlig chans att åtgärda det. Vi läser varje rapport.

Vanliga frågor