Svi korisnici ne bi trebalo da imaju pristup svim zadacima. Na primer samo studenti MATFa treba da vide određene zadatke.
Ograničenje neće biti postavljeno na nivou zadatka, nego na nivou pregledača. Na primer studenti MATFAa imaju pristup svim zadacima sa bazom stud2020, a za te zadatke je zadužen pregledač stud2020.
Svali korisnik ima svoju ulogu (Role). Uloga može biti admin, profesor, student ili ostali. S tim da postoji mogućnost dodavanja uloga.
Tabela ROLE_GRADER_PERMISSION daje prava pristupa određenom pregledaču određenoj ulozi. Tabela sadži naredne dve kolone:
graderId - strani ključ ka tabeli pregledača (grader), deo primarnog ključa
roleId - strani ključ ka tabeli uloga (Role), deo primarnog ključa.
Ukoliko stud2020 pregledač ima id 1, uloga studenta id 3 onda će studen imati pristup zadacima za stu2020 ukoliko se u tabeli permission-a nalazi red (1, 2).
Prava pristupa se mogu dodati i ukloniti slanjem odgovarajućeg POST zahteva na /roleGraderPermission/removePermission odnostno /roleGraderPermission/addPermission. U oba slučaja telo zahteva izgleda ovako:
{
"roleId": 1,
"graderId": 2
}
Da bi se videla prava zahteva može se poslati GET zahtev na /roleGraderPermission/getAllPermissions.
Korisnik će u zavisnoti od svoje uloge dobiti zadatke kojima ima pristup. Da bi se izbeglo izvršavanje upita svakim zahtevom korisnika za zadatke, lista zadatak će biti čuvana u fajlu, i slato odatle. Kako se lista zadatka razlikuje od korisnika do korisnka, svaka uloga će imati odgovarajući fajl. Na primer zadaci za studenti će se čuvati u student_zadaci.
Naredni zahtev vezan za implementaciju ograničenja pristupa korisnika je davanje uloga korisnicima. Običan korisnik ne treba da ima mogućnost da se predstavi kao student. Postoji nekoliko načina da se implementira davanje uloge korisniku pri kreiranju i izmeni:
U kodu bi mogli dodati jedan if koji proverava uslove. Na primer za studenta da je mejl u formatu mi@alas.matf.bg.ac.rs i da je korisničko ime u formatu mi. Problem sa ovim načinom je teža modifikacija. Na primer ako se fomat mejla promeni potrebno je izmeniti kod, rekompajlirati, zaustaviti server i pokrenuti novu verziju. Ideja je napraviit takav server da je moguće proširiti ga što više bez izmene koda.
Drugi način bi bio napraviti novu tabelu sa zatevima za određenu ulogu, ili proširiti tabelu uloga da sadrže dodatne kolone. Na primer da tabela uloga ima kolone regex_email i regex_name, pa da se to proverava pri kreiranju korisnika. U ovom slučaju može biti potreban dodatan pristup bazi pri kreiranju korisnika i provera više uslova, iako je i ovo rešenje prihvatljivo.
Treće rešenje koje je i implementirano je da se koriste triggeri za proveru uloga. Pre unosa ili izmene korisnika treba proveriti ulov za mejl i korisničko ime. Izmena trigera ne zahteva zaustavljanje servera, iako bi bilo potrebno izmeniti bazu pri promeni zahteva.
Svi korisnici ne bi trebalo da imaju pristup svim zadacima. Na primer samo studenti MATFa treba da vide određene zadatke. Ograničenje neće biti postavljeno na nivou zadatka, nego na nivou pregledača. Na primer studenti MATFAa imaju pristup svim zadacima sa bazom stud2020, a za te zadatke je zadužen pregledač stud2020. Svali korisnik ima svoju ulogu (Role). Uloga može biti admin, profesor, student ili ostali. S tim da postoji mogućnost dodavanja uloga.
Tabela ROLE_GRADER_PERMISSION daje prava pristupa određenom pregledaču određenoj ulozi. Tabela sadži naredne dve kolone:
Ukoliko stud2020 pregledač ima id 1, uloga studenta id 3 onda će studen imati pristup zadacima za stu2020 ukoliko se u tabeli permission-a nalazi red (1, 2).
Prava pristupa se mogu dodati i ukloniti slanjem odgovarajućeg POST zahteva na
/roleGraderPermission/removePermissionodnostno/roleGraderPermission/addPermission. U oba slučaja telo zahteva izgleda ovako:Da bi se videla prava zahteva može se poslati GET zahtev na
/roleGraderPermission/getAllPermissions.Korisnik će u zavisnoti od svoje uloge dobiti zadatke kojima ima pristup. Da bi se izbeglo izvršavanje upita svakim zahtevom korisnika za zadatke, lista zadatak će biti čuvana u fajlu, i slato odatle. Kako se lista zadatka razlikuje od korisnika do korisnka, svaka uloga će imati odgovarajući fajl. Na primer zadaci za studenti će se čuvati u student_zadaci.
Naredni zahtev vezan za implementaciju ograničenja pristupa korisnika je davanje uloga korisnicima. Običan korisnik ne treba da ima mogućnost da se predstavi kao student. Postoji nekoliko načina da se implementira davanje uloge korisniku pri kreiranju i izmeni: