OK, npr. zavrsili smo izdadu nase aplikacije.
Logicno je da na pocetku korisnik mora da upise svoje korisnicko ime i npr. lozinku. Ako je to pravilno uneto, korisnik ulazi u aplikaciju, u suprotnom, trazi se ponovna prijava ili se iskljucuje.
Ovo se realizuje primenom jedne tabele sa imenima i lozinkama korisnika, kojoj pristup ima jedino administrator aplikacije.
Moglo bi se napraviti jos da svaki korisnik moze po svojoj zelji da promeni svoju lozinku, ako to pozeli, radi sigurnosti.
Naravno, sve ovo je potrebno da bi se kasnije koristilo ime korisnika, kada u slogovima koji se azuriraju treba upisati ime korisnika koji je zadnji izvrsio izmenu, sa dodavanjem datuma i vremena izmene. Ovim ubedimo korisnike da se pamti ko je sta radio, tako da treba obratiti paznju kod unosa podataka.
Ali ovo je samo pocetak zastite. Korisnicima treba zabraniti meni sa servisnim programima u kome su npr. pregledi korisnika, tabela prijava, podesavanje parametara programa, idenata u tabelama... Ovaj zahtev bi se mogao obezbediti sa jednim poljem u tabeli korisnika, sa A=administrator ili K=korisnik, pa da se uvek kod postavke aplikacije gleda i ovaj podatak.
Ali ovo se komplikuje kada korisnicima treba osim servisnih opcija, zabraniti i npr. neku grupu menija koja nije u njihovom domenu rada (npr. rad sa podacima o racunarima u mrezi, ...). Ovo bi takodje moglo da se odradi uvodjenjem novih polja u tabelu korisnika za svaku grupu osnovnog menija, mada mi se ovo vec ne dopada, jer sistem nije fleksibilan, tako da bi uvek u toku prosirenja aplikacije morala da se menja i struktura baze korisnika i unos privilegija.
Sledeca komplikacija: ajde da sad kod svake opcije menija koja odradjuje neki podprogram odredimo da li korisnik moze da pristupi toj opciji ili ne. To je vec mnogo za onu tabelu korisnika i razmisljam o nekoj novoj tabeli sa definisanjem imena korisnika i opcijama menija koje moze ili ne moze da koristi. Ali moraju se onda za svakog novog korisnika nanovo unositi mnogobrojni podaci.
I na kraju, finale komplikovanja: neki korisnik moze samo da gleda podatke u otvorenoj tabeli, drugi moze i da ih menja, treci moze i da ih brise. Tek kada ovo obezbedimo, cini mi se da smo spremni da pustimo aplikaciju u koriscenje u mreznom ili visekorisnickom radu.
Pitanje se odnosi na Vasa iskustva u ovoj oblasti, kako ste Vi to resavali, kako ste organizovali tabele sa definisanjem privilegija korisnicima, i kako ste obezbedili da se privilegije lako unose za veci broj korisnika.
Nije hitan odgovor, prikljucite se kad budete imali vremena za ovu diskusiju.
Logicno je da na pocetku korisnik mora da upise svoje korisnicko ime i npr. lozinku. Ako je to pravilno uneto, korisnik ulazi u aplikaciju, u suprotnom, trazi se ponovna prijava ili se iskljucuje.
Ovo se realizuje primenom jedne tabele sa imenima i lozinkama korisnika, kojoj pristup ima jedino administrator aplikacije.
Moglo bi se napraviti jos da svaki korisnik moze po svojoj zelji da promeni svoju lozinku, ako to pozeli, radi sigurnosti.
Naravno, sve ovo je potrebno da bi se kasnije koristilo ime korisnika, kada u slogovima koji se azuriraju treba upisati ime korisnika koji je zadnji izvrsio izmenu, sa dodavanjem datuma i vremena izmene. Ovim ubedimo korisnike da se pamti ko je sta radio, tako da treba obratiti paznju kod unosa podataka.
Ali ovo je samo pocetak zastite. Korisnicima treba zabraniti meni sa servisnim programima u kome su npr. pregledi korisnika, tabela prijava, podesavanje parametara programa, idenata u tabelama... Ovaj zahtev bi se mogao obezbediti sa jednim poljem u tabeli korisnika, sa A=administrator ili K=korisnik, pa da se uvek kod postavke aplikacije gleda i ovaj podatak.
Ali ovo se komplikuje kada korisnicima treba osim servisnih opcija, zabraniti i npr. neku grupu menija koja nije u njihovom domenu rada (npr. rad sa podacima o racunarima u mrezi, ...). Ovo bi takodje moglo da se odradi uvodjenjem novih polja u tabelu korisnika za svaku grupu osnovnog menija, mada mi se ovo vec ne dopada, jer sistem nije fleksibilan, tako da bi uvek u toku prosirenja aplikacije morala da se menja i struktura baze korisnika i unos privilegija.
Sledeca komplikacija: ajde da sad kod svake opcije menija koja odradjuje neki podprogram odredimo da li korisnik moze da pristupi toj opciji ili ne. To je vec mnogo za onu tabelu korisnika i razmisljam o nekoj novoj tabeli sa definisanjem imena korisnika i opcijama menija koje moze ili ne moze da koristi. Ali moraju se onda za svakog novog korisnika nanovo unositi mnogobrojni podaci.
I na kraju, finale komplikovanja: neki korisnik moze samo da gleda podatke u otvorenoj tabeli, drugi moze i da ih menja, treci moze i da ih brise. Tek kada ovo obezbedimo, cini mi se da smo spremni da pustimo aplikaciju u koriscenje u mreznom ili visekorisnickom radu.
Pitanje se odnosi na Vasa iskustva u ovoj oblasti, kako ste Vi to resavali, kako ste organizovali tabele sa definisanjem privilegija korisnicima, i kako ste obezbedili da se privilegije lako unose za veci broj korisnika.
Nije hitan odgovor, prikljucite se kad budete imali vremena za ovu diskusiju.
