[ ultraKeen @ 15.10.2002. 11:01 ] @
kako organizovati pristupna prava NEPOZNATIM korisnicima sa neta, a da oni koriste bazu preko role-a ? ... dobro ne bas toliko nepoznatim, nego vec (ranije) registrovanim u bazi...

znam da se takvi trebaju konektovati sa:

CONNECT 'filespec'
USER 'username' PASSWORD 'password' ROLE 'rolename'

ali - sta posle ?

tj. kako organizovati dodelu prava rolama nad procedurama a ovima nad tabelama pa da nikada niko sa mreze ne moze pipnuti tabele... ja bi tako bar voleo :)

(patim se i patim se al' nikako da proradi...)

a u zadnje vreme se pitam da li je uopste i potrebno registrovati korisnike sa neta, zato isti/nepoznati sa neta ne bi odmah uskakali u neke role pa radili samo/sve ono sto je njima/rolama omoguceno da rade...?
[ ultraKeen @ 17.10.2002. 02:47 ] @
novi korisnici sa neta se ne moraju registrovati ako se svaki od njih prijavljuje kao jedan od ranije vec definisanih, da kazem - meta-korisnika, sto je slicno konceptu rola, i kada bi se stvarna evidenicija o njima (nalog, passw.) dodatno vodila u posebnoj/dodatnoj tabeli koja nije sistemska, pored one sistemske USERS iz isc4.gdb... naravno bilo bi vise takvih meta-korisnika, tacno onoliko koliko i potrebnih rola

klasicnije cini mi se resenje je da zaista svaki korisnik sa neta bude prvo posebno registrovan u tabeli USERS sistemske baze isc4.gdb, u kom slucaju bi morao da postoji nekakav stalno aktivan user kome bi to pravo INSERT-a bilo omoguceno GRANT-om od strane SYSDBA usera... "stalno aktivan user" u programskom smislu...

a na bilo koje resenje od ta dva, dolazi jedan zaista nepoznati user (zaista registrovan kao takav u isc4.gdb\USERS, recimo "unknown"), na ciji bi se nalog prijavljivali svi koji recimo samo hoce da vide cega tu sve ima tj. koji samo mogu da SELECT-uju i nista vise...

jesam li u pravu ? ... ili ima boljih resenja
[ mbabuskov @ 13.11.2002. 14:42 ] @
Citat:
ultraKeen:
tj. kako organizovati dodelu prava rolama nad procedurama a ovima nad tabelama pa da nikada niko sa mreze ne moze pipnuti tabele... ja bi tako bar voleo :)


Sta si mislio pod "ne moze pipnuti tabele"? Da li da ne moze da uradi ni select iz njih, ili da moze da radi samo select, ili da ne moze da im menja strukturu, ili da bas nista ne moze?

U svakom slucaju, ne moras se patiti sa stored procedurama, view-ovi mnogo lepse rade taj posao. Npr, imas tabelu ptt brojeva mesta:

CREATE TABLE mesto
(
PTT char(5),
NAZIV char(30)
);

e, sad kazes ovako:

REVOKE ALL ON MESTO FROM PUBLIC;

tj. ni jedan korisnik ne moze da pristupa tabeli. I onda kreiras rolu, ili za svakog korisnika pojedinacno radis:

GRANT SELECT ON MESTO TO naziv_usera_ili_role;

E, sad, ako bas ne zelis da ti dira tabelu direktno, napravis mu view, koji sadrzi samo one podatke koje zelis da das:

CREATE VIEW mesto_dozvoljeno
AS
SELECT * FROM mesto WHERE ptt like '11%';

GRANT SELECT ON mesto_dozvoljeno TO naziv_usera/role;

Tako si mu npr. dao da samo vidi mesta ciji ptt broj pocinje sa 11. Pogledaj malo dokumentaciju za View-ove (otprilike isto rade na svim bazama podataka).