Безбедност

Автентикација

Сметките ги управува Supabase Auth со е-пошта и лозинка, Google OAuth или GitHub OAuth. По најавата, вашиот прелистувач држи сесиски токен (JWT) кој автоматски се освежува од страна на middleware-от на платформата, па работна сесија тивко не истекува среде работа.

API-то го прифаќа тој сесиски токен во две форми: како сесиско колаче кое контролната табла и онака го испраќа, или како заглавие Authorization Bearer. Програмскиот пристап без најава преку прелистувач користи API-клучеви наместо тоа, опишани подолу. Крајните точки одбиваат барања без валиден акредитив; само изречно јавните патеки, како проверката на здравје и контакт-формуларот, функционираат неавтентицирано.

Улоги и дозволи

Секоја сметка има точно една улога: CLIENT, OPERATOR или ADMIN. Клиентите поседуваат роботи и плаќаат за сесии, операторите управуваат со роботи и заработуваат од сесии, а администраторите ја водат платформата. Избирате меѓу клиент и оператор при onboarding; улогата ADMIN се доделува од администраторите на платформата и не може да се самоизбере.

Проверките на улогата се случуваат на страна на серверот при секое барање, не во UI. Под API-то, пристапот до базата на податоци е дополнително ограничен со row-level security политики, па дури и грешка во крајна точка не се претвора во слободен пристап до редовите на други сметки.

API-клучеви

API-клучевите им даваат пристап на скрипти и сервери без најава преку прелистувач. Ги создавате и повлекувате во /dashboard/settings; клучевите го носат префиксот ayr_live_ и се испраќаат како заглавие Authorization Bearer. Клуч дејствува со улогата и дозволите на сметката која го создала, па изложен клуч е точно толку лош колку и изложена лозинка.

• Чувајте ги клучевите на страна на серверот. Не им е местото во клиентски JavaScript, мобилни апликации или јавни репозиториуми.
• Користете еден клуч по интеграција. Кога нешто ќе се изложи, сакате да повлечете еден потрошувач, не сите.
• Ротирајте без прекин: прво создадете го заменскиот клуч, распоредете го, потоа повлечете го стариот клуч во /dashboard/settings.
• Повлечете веднаш при каква било сомнеж. Создавањето нов клуч чини секунди; напаѓач со валиден клуч може да прави сѐ што може вашата сметка.

Мерки за време на управување во живо

Управувањето во живо е врзано за закуп на сесија. Робот прифаќа команди само додека е во точно една ACTIVE сесија, и само од операторот кој ја држи таа сесија; самиот робот е означен како IN_SESSION за сите останати. Оператор може да држи најмногу една ACTIVE или PAUSED сесија во исто време, што исклучува една личност номинално да управува со две раце истовремено.

Кокпитот обезбедува итно запирање кое веднаш ја запира раката, а паузирањето или завршувањето на сесијата го запира протокот на команди во целина. Покрај тоа, платформата ја следи активноста на операторот: по период без внес се испраќа предупредување за неактивност, а ако операторот остане неактивен, сесијата се запира автоматски. Тоа ги штити двете страни, клиентот од плаќање празно време и роботот од стоење во неконтролирана состојба со активен закуп.

Ревизорски запис

Секоја сесија чува записник на настани: почеток и крај, паузи и продолжувања, проверки на активност, предупредувања за неактивност, промени на оператор, барања за продолжување и грешки, секое со временски печат. Кога се прегледува спор, овој записник на настани е примарниот доказ, што е уште една причина платформата да го запишува автоматски наместо да се потпира на нечие сеќавање.

Надвор од сесиите, значајните дејства на платформата се запишуваат во ревизорски запис со id на корисникот кој дејствувал, дејството, засегнатиот ресурс и метаподатоци. Промените на профил, трансакциите значајни за плаќања и дејствата на администраторите оставаат записи. Ревизорските записи ги пишува платформата и не се уредливи преку кој било интерфејс за корисници.

Криптирање и заштита на податоци

Сиот сообраќај до и од платформата е криптиран во пренос со TLS, вклучувајќи видео потоци и контролни сигнали. На слојот на податоци, row-level security политики го ограничуваат пристапот до базата по сметка. Податоците за плаќање се најјасната граница од сите: картичките и банкарските податоци ги обработува исклучиво Stripe и никогаш не допираат до серверите на AY-Robots.

Пријавување ранливост

Ако најдете безбедносен проблем, пријавете го одговорно преку страницата /security или формуларот /contact користејќи ја категоријата Bug Report. Вклучете што сте нашле, каде, и како да се репродуцира; не пристапувајте до податоци на други корисници надвор од минимумот потребен за да го демонстрирате проблемот, и не објавувајте детали пред да имаме разумна прилика да го поправиме. Читаме секоја пријава.

Често поставувани прашања