Pozdrav!
To sto ti hoces se radi upravo onim skriptom (postavljen je link).
S' obzirom da Forms nije "kulturan" (ne predstavlja se svojim imenom i nije takav kako se ocekuje da bude) ostaje ti samo da se koristis "prljavim" trikovima i PSEUDO-resenjima.
Evo ti 4 potencijalna resenja (svi su slicni i baziraju se na extra kodiranje):
I
- U OEM podesis DEFAULT PROFIL da ne dozvoljava ni jednu konekciju.
- U OEM dodas jos jedan profil (npr Aplikacija profil) koja moze da koristi maximalno 2 konekcije - Forms koristi jednu a Reports otvara drugu konekciju za sebe
- Svi korisnici koji koriste tu aplikaciju imaju profil Aplikacija. Ostali imaju DEFAULT profil...
Rezultat: Korisnici koji koriste aplikaciju ce moci da koriste bazu nesmetano, ostali... ne
Problem: Korisnici koji koriste aplikaciju ce i dalje moci da se zakace pomocu nekih alata na bazu
II
- Jedan korisnik je vlasnik sheme i svih procedura/funkcija/paketa
- Ostali korisnici NEMAJU prava da pristupe shemi gde je aplikacija
- U formsu prepravis LOGON proceduru, da se aplikacija uvek prijavljuje na bazu kao VLASNIK SHEME. U isto vreme (procedurom/funkcijom) SAM proveris da li postoji korisnik koji se loguje. Ako postoji - pustas da radi, a ako ne postoj - napravis ljubaznu formu: BEGAJ BRE!
Rezultat: Korisnici ce moci da koriste samo aplikaciju i nece moci da pristupe SHEMI.
Problem: I dalje ce moci da se koriste ostali alati za pristup bazi ukoliko imaju naloge na bazi.
III
- Diskretno promenis port preko koga ide komunikacija. Npr. od 1521 prebacis na 15210 ili 1621 ili na nesto nebulozno 6543...
- Prepravis LOGON proceduru prve forme, samo toliko da koristi novi port.
opciono: - Zabranis koriscenje porta 1521 u mrezi - preko FW
Rezultat: Korisnici ce i dalje moci da koriste aplikaciju i NISTA drugo
Problem: 0.01 promil tvojih korisnika ce umeti da iskoristi NETSTAT ili nesto slicno i da skenira tu maxinu i da ukapira na kom portu je listener i pri tom da to sto su nasli umeju da primene kroz ostale alatke...
IV
- Napravi svoj User Management (tabela ili nekoliko tabela gde ces da upisujes korisnike aplikacije i eventualno njihova prava)
- Prepravi LOGON proceduru u formsu da se loguje uvek kako jedan korisnik i da pri tom proverava te tvoje tabele. Pa ako postoji covek, procitas njegova prava i pustas da radi vodeci pri tom racuna (ako je potrebno) koju formu pokrece, a ako ne postoji... ljubazna forma...
Postoji i jos jedno resenje (citao sam o tome, ali nisam probao a i ne preporucujem ti da se mnogo igras sa ovim):
V
- Postaviti u FORMS neku varijablu sa nekom egzoticnom vrednoscu
- Prepraviti AFTER LOGIN u bazi da nekako procita tu varijablu... pa ako je ima i poznata mu je, dozvoljava konekciju, a ako nema... ljubazno obavestenje
Resenje: Upravo ono sto ti hoces
Problem: Kako da se ta vrednost procita? Odavno sam citao da to moze da se uradi... ali nikad nisam imao petlje da se igram u AFTER LOGIN trigeru na produkcionoj bazi... jer, ako tu zajebes situaciju... mnogo si zabrljo...
Sta da ti kazem... Kombinuj resenja.
Mozda nije bas ono sto ti hoces, ali ce krajnje da zakomplikuje nekom znatizeljiku posao...
PS. Ako detaljno opises kakva je to baza (tj, sta se sve od aplikacija nalazi u njoj), kako su organizovani korisnici (role, profili, itd..) i kako je sve to zamisljeno i kako funkcionise, dobices mnogo detaljnije pseudo-resenje koje ce odsimulirati upravo ono sto ti hoces...
Kako zaštiti Oracle bazu od drugih konekcija
