Security

Authentication

Pinamamahalaan ng Supabase Auth ang mga account gamit ang email at password, Google OAuth, o GitHub OAuth. Matapos mag-log in, hawak ng browser mo ang isang session token (isang JWT) na awtomatikong ni-refresh ng platform middleware, kaya hindi tahimik na mag-e-expire ang gumaganang session sa gitna ng trabaho.

Tinatanggap ng API ang session token na iyon sa dalawang anyo: bilang session cookie na ipinapadala na ng dashboard, o bilang Authorization Bearer header. Gumagamit ng API key ang programmatic access na walang browser login, na ipinapaliwanag sa ibaba. Tinatanggihan ng mga endpoint ang request na walang valid na credential; ang mga explicit na public na route lang, tulad ng health check at contact form, ang gumagana nang walang authentication.

Role at permission

May eksaktong isang role ang bawat account: CLIENT, OPERATOR, o ADMIN. Nagmamay-ari ang mga kliyente ng robot at nagbabayad para sa session, kinokontrol ng mga operator ang robot at kumikita mula sa session, at pinapatakbo ng mga admin ang platform. Pumipili ka sa pagitan ng client at operator habang nag-o-onboard; itinatalaga ng platform administrator ang admin role at hindi ito puwedeng piliin nang mag-isa.

Nangyayari ang role check sa server-side sa bawat request, hindi sa UI. Sa ilalim pa ng API, mas na-restrict pa ang database access gamit ang row-level security policy, kaya hindi nagiging libreng access sa mga row ng ibang account kahit may bug sa isang endpoint.

Mga API key

Binibigyan ng API key ang mga script at server ng access nang walang browser login. Ginagawa mo at binabawi mo ang mga ito sa /dashboard/settings; may prefix na ayr_live_ ang mga key at ipinapadala bilang Authorization Bearer header. Kumikilos ang isang key na may role at permission ng account na gumawa nito, kaya kasing sama ng nakikitang password ang isang na-leak na key.

• Panatilihin ang mga key sa server-side. Hindi sila dapat mapunta sa client-side JavaScript, mobile app, o public repository.
• Gumamit ng isang key kada integration. Kapag may nag-leak, gusto mong bawiin ang isang consumer, hindi lahat.
• I-rotate nang walang downtime: gumawa muna ng kapalit na key, i-deploy ito, tapos bawiin ang lumang key sa /dashboard/settings.
• Bawiin kaagad kapag may hinala. Segundo lang ang gastos sa paggawa ng bagong key; kahit ano ang kaya ng account mo ay kaya ng attacker na may valid na key.

Mga safeguard habang live ang kontrol

Nakatali sa isang session lease ang live control. Tumatanggap lang ng command ang robot habang nasa eksaktong isang ACTIVE session ito, at mula lang sa operator na humahawak sa session na iyon; naka-mark ang robot mismo bilang IN_SESSION para sa lahat ng iba. Isang ACTIVE o PAUSED na session lang ang puwedeng hawakan ng operator nang sabay, na nag-aalis ng posibilidad na isang tao lang ang nominal na kumokontrol sa dalawang arm sabay-sabay.

Nagbibigay ang cockpit ng emergency stop na agad na humihinto sa arm, at hinihinto ng pag-pause o pagtatapos ng session ang buong daloy ng command. Bukod dito, sinusubaybayan ng platform ang activity ng operator: matapos ang panahong walang input, nagpapadala ito ng inactivity warning, at kung mananatiling inactive ang operator, hihinto nang awtomatiko ang session. Pinoprotektahan nito ang parehong panig, ang kliyente mula sa pagbayad para sa idle time at ang robot mula sa pagiging naiwan sa isang uncontrolled na estado na may buhay na lease.

Audit trail

Nagpapanatili ang bawat session ng event log: simula at katapusan, pag-pause at pag-resume, activity check, inactivity warning, operator switch, extension request, at error, na may timestamp ang bawat isa. Kapag rinepaso ang isang dispute, ang event log na ito ang pangunahing ebidensya, na isa pang dahilan kung bakit isinusulat ito ng platform nang automatic sa halip na umaasa sa alaala ng kahit sino.

Lampas sa mga session, naitatala ang mahahalagang aksyon sa platform sa isang audit log kasama ang user id ng gumawa, ang aksyon, ang apektadong resource, at metadata. Nag-iiwan ng entries ang mga pagbabago sa profile, mga transaksyong may kinalaman sa bayad, at aksyon ng admin. Isinusulat ng platform ang mga audit record at hindi ito ma-e-edit sa pamamagitan ng anumang user-facing na interface.

Encryption at proteksyon ng data

Naka-encrypt sa transit gamit ang TLS ang lahat ng traffic papunta at galing sa platform, kasama ang video stream at control signal. Sa data layer, ni-restrict ng row-level security policy ang database access kada account. Ang payment data ang pinakamalinaw na hangganan sa lahat: hinahawakan lang ng Stripe ang card at bank detail at hindi kailanman dumadaan sa AY-Robots server.

Pag-report ng vulnerability

Kung makakita ka ng security issue, i-report ito nang responsable sa pamamagitan ng /security page o ng /contact form gamit ang Bug Report category. Isama kung ano ang nakita mo, saan, at paano ito i-reproduce; huwag mag-access ng data ng ibang user lampas sa minimum na kailangan para ipakita ang isyu, at huwag maglathala ng detalye bago kami magkaroon ng makatwirang pagkakataong ayusin ito. Binabasa namin ang bawat report.

Mga madalas itanong