Paano pinoprotektahan ng SCALE Order ang datos ng inyong restaurant

Bawat restaurant sa sarili nitong espasyo

Tumatakbo ang lahat ng restaurant sa iisang platform, pero ang database ang nagpapatupad ng paghihiwalay. Naka-on at sapilitang ipinapatupad ang row-level security sa bawat table ng restaurant, at tumatakbo ang bawat request sa isang transaction na nakatakda sa iisang restaurant. Hindi kayang lampasan ng account na ginagamit ng application ang mga patakarang iyon.

Dalawang internal na role ang pinahihintulutang lumampas sa mga ito para sa makikitid na gawain: ang mga background worker, na puwede lang maglista kung aling mga restaurant ang aktibo bago gawin ang kanilang trabaho nang isa-isang restaurant, at ang control center ng SCALE team, na walang access sa mga address ng customer, lokasyon ng order, password hash o sa sariling mga audit log ng mga restaurant.

Pag-sign in at mga password

• 8 hanggang 128 character ang mga password at iniimbak ang mga ito bilang scrypt hash na may random na salt; pinaghahambing ang mga ito sa constant time.
• Nila-lock ang account nang 15 minuto pagkatapos ng limang maling password. Pareho ang tagal ng pag-sign in sa account na hindi umiiral, kaya hindi nito ibinubunyag kung aling mga account ang umiiral.
• Nililimitahan din ang mga pagtatangkang mag-sign in bawat address sa loob ng 15 minuto: 10 para sa staff, 60 para sa mga customer, 5 bagong rehistro ng customer. Pinaghahatian ng bawat server ang mga bilang na ito.
• 6 na digit ang mga verification code, nag-e-expire pagkalipas ng 10 minuto at may limitadong bilang ng pagsubok.
• Puwedeng i-on ang proteksyon ng Cloudflare laban sa bot para sa pag-sign in at sa paglalagay ng order.

Mga session na hindi magagamit muli

Nagbibigay ang pag-sign in ng panandaliang access token (15 minuto bilang default) at ng refresh token. Pinapalitan ng bawat refresh ang refresh token ng bago. Kung gamitin muli ang luma, tinatapos ang buong kadena ng mga session, kaya hindi magagamit nang matagal ang ninakaw na token.

Sinusuri rin ng bawat request kung aktibo pa ang session, kaya kapag inalis ang isang staff, pinalitan ang kanyang password o binawasan ang kanyang role, agad siyang nasa-sign out saanman. Hindi mababasa ng mga script sa pahina ang mga cookie ng console at hindi ipinapadala ng ibang site ang mga ito.

Mga role na may pinakamaliit na kinakailangang access

Binubuo ang access mula sa 29 na pahintulot, mula sa pagbasa ng mga order hanggang sa pagkumpirma ng cash o pamamahala ng staff. Puwedeng gumawa ang may-ari ng mga role na may anumang kombinasyon ng mga ito, at puwedeng limitahan ang staff sa iisang sangay. Walang makapagbibigay ng pahintulot na wala sa kanya mismo, hindi mae-edit ang mga built-in na role, at hindi maaalis ang huling aktibong may-ari.

Itinatago ng console ang hindi magagamit ng isang role, pero para lang ito sa linaw: sinusuri ng server ang pahintulot, ang sangay at ang pagiging miyembro sa bawat aksyon.

Mga record na hindi maisusulat muli

Puwede lang dagdagan ang mga pagbabago ng status ng order, ang ledger ng puntos, ang galaw ng stock, ang history ng presyo at ang audit log. Tinatanggihan ng database ang anumang pag-update o pagbura, kaya ginagawa ang mga pagwawasto sa pamamagitan ng pagdaragdag ng bago at nakikitang entry.

Paggalang sa datos ng mga customer

• Kinukuha lang ang lokasyon ng order habang bukas ang app, nang may pahintulot, at binubura ito pagkalipas ng 180 araw.
• Puwedeng burahin ng mga customer ang kanilang account mula sa website o app. Inaalis ang kanilang mga address, lokasyon, device, notification at password, at ginagawang anonymous ang kanilang profile.
• Para hindi na muling makakuha ng mga alok para sa bagong customer ang iisang tao, mga protektadong fingerprint lang ng kanilang phone at email ang itinatago.