Fleksibilnost i sigurnost

 

Ovaj API moze zadovoljit potrebe svi tipova korisnika.

Mozete u vasem sistemu cuvati sve podatke dobijene od api ali to nije neophodno. Za "lake" implementacije dovoljno je koristiti samo identifikaciju inicijalo kreirane naruđzbine da bi se izvršile sve eventualno/naknadno potrebne operacije.

Podaci se cuvaju u prostoru za podatke API-ja i na ESIR-u. Eventualno cuvanje i u vašem sistemu bi bila treća kopija podataka.

Fiskalizaciju na vašem sajtu/aplikaciji uz ovaj API mozete resiti sa par linija koda na strani potvrde naruđzbine.

API podrzava 3 tipa autorizacije koji mogu zadovoljiti svaki slucaj.

1. Autorizacija preko backtoken-a (pun pristup)

Ovo je klasicna oauth autorizacija (PIB+SITEUID+HOLESTKEY+PASSWORD) cije je rezultat token trajanja do 24h.

Ovaj token (backtoken) se upisuje kao header u sve web zahteve i to ih autorizuje za izvrsenje.

Ovaj vid autorizacije daje pun pristup svim funkcijama API-ja i mora se koristiti unutar vaseg server-a.

Ukoliko koristite vaš server kao posrednu tačku koja će izvršavati sve zahteve ostale opcije autorizacije vam nisu potrebne.

Da bi dobili backtoken morate imati pristup sigurnosnim podacima najviseg nivoa. Na vasem serveru moze postojati konfiguracioni fajl koji ih sadrzi i koji normalno nije eksponiran van.

Ako zelite neke lakse i brze implementacije koje ne zahtevaju da sve zahteve provučete kroz server i programski kod onda možete koristiti alternativne metode autorizacije.

"backtoken" (i pogotovu lozinka ili upotrebni kljuc) ne smeju biti dostupni na frontendu vašeg sajta ili u aplikaciji.

Klijenti losih namera, malware ekstenzije, crni browseri(modifikovani) ili XSS ubaceni kodovi u web browser-u mogu pokupiti ovaj token i preko njega načiniti štetu firmi.

Napomena: SSL (HTTPS) komunikacija u vasoj aplikaciji ne resava sigurnosne probleme. Root-ovani | Jailbreak-ovani uredjaji mogu biti izmenjeni tako da citaju memoriju vase aplikacije ili sve podatke iz komunikacionog socket-a posle SSL dekripcije. Motivisane strane ne moraju biti ni previše tehnički potkovane jer postoje gotovi build-ovi android-a koji daju korisniku lak pristup ovim podacima!!!

2. Autorizacija preko fronttokena-a (klijentske operacije)

Fronttoken je kratkotrajna autorizacija koja organicava korisnika na njegovu naridzbinu/narudzbine. Moze se zadati dozvoljeni broj kreiranja fiskalnih dokumenata i citanja. Dodatno moze ograniciti IP adrese sa kojih klijent sme da salje zahteve.

Fronttoken se sme naci u DOM-u strane webbrowser-a ili memoriji aplikacije.

2.1 fronttoken dobijen preko poziva autorizovanog backtoken-om

Na vasem serveru je dovoljno dodati opciju izdavanja fronttoken-a.

Server ima dostupne sigurnose podatke najviseg nivoa koje cuva na sigurnoj lokaciji i ne eksponira, a klijetima samo generise fronttoken-e po zahtevu za naridzbinu/narudzbine.

Pogodno za IOS|Android aplikacije, REACT, VUE, ANGULAR, ChatGPT, Bard ili sl. web aplikacije.

2.2 fronttoken dobijen preko poziva autorizovanog sigurnosnim hash stringom

Ne moze se koristiti iz aplikacije (jer bi SECRET_KEY morao da bude ili ugradjen u kod ili nekako iscitavan). Primenjivo samo za web. Umesto sigurnosnih podatka najviseg nivoa server poseduje SECRET_KEY podatak. Preko njega pravi webpermissionstring koji se moze proslediti kao header da bi se dobio fronttoken.

Server ne sme da eksponira SECRET_KEY ali dovoljno je da ima opciju md5 funkcije da bi napravio webpermissionstring koji se sme dati klijentskoj strani kako bi se potrazio fronttoken iz javascrip-a.

Primer za upotrebu ovog tipa autorizacije je Shopify. Shopify LIQUID templejt jezik ima md5 funkciju i moze kreirati webpermissionstring za upotrebu iz javascript-a. SECRET_KEY ostaje deo LIQUID koda u templejt fajlovima koji se ne eksponira ka klijentu.