Terve... tämä kysymys nyt vähä liittyy kumpaakin MySQL sekä MySQL .
Pitäisi saada tehtyä tauluja mihin käyttäjillä on oikeus tai ei ole oikeutta.
Mikä on paras tapa tehdä tämä, sekä tarkistaa ne käyttöoikeudet, esim
muokkaus, lukeminen jne.
Tätä tehdään Win32 api projektina ja yllättäen clienttiä ajetaan windowssissa.
Tattis.
Pitäisi saada tehtyä tauluja mihin käyttäjillä on oikeus tai ei ole oikeutta.
Mikä on paras tapa tehdä tämä, sekä tarkistaa ne käyttöoikeudet, esim
muokkaus, lukeminen jne.
Tätä tehdään Win32 api projektina ja yllättäen clienttiä ajetaan windowssissa.
Tattis.
Vastaukset 5
Vanhimmat
Käyttäjälle ei mitään oikeuksia mihinkään tauluun.
KAikki käpälöinti DB prosarien kautta.
DB prosarien alkun tarkistus
IF userHasRights(Käyttäjänimi, Taulu, toiminto) then
...thedään hommat
else
...heitetään herja
END IF
userHasRights funkkri väsätään tarkistamaan userRights taulusta onko oikeutta vai ei.
UserRights taululle ainakin kentät
Username VARCHAR
Tablename VARCHAR
Operation VARCHAR
allowed BOOL
Josko tuolla menisi?
Niin noin sitä nopeasti ajattelisi.
Mutta jos sulla ei ole oikeutta tietokantaan tai oikeuden tasoa ei tiedetä, miten pääset kirjautumaan edes koko kantaan.
Sitten tuli lisää kysymyksiä. Onko tietokannassa tällästä taulun sisäistä pois sulkevaa mekanismia?
Tässä on pankkitili taulu esimerkiksi.
tilinro char(20),
// jompi kumpi on pakollinen, mutta käytetään ibania jos se on?
// tyyliin NOT NULL IF IBAN EXISTS tai jotain...
iban char(18),
bic char(11),
On kyllä paljon oppimista tälläkin saralla.
on irrallinen objektikohtaisista oikeuksista.
Voi aivan hyvin olla oikeus kirjautua mutta ei tehdä mitään muuta kuin suorittaa prosareita.
ILman prosaritekniikkaa joudut granttaamaan jokaisen taulun select, update, delete ja insert oikeuden jokaiselle käyttäjälle erikseen ja ylläpitämään N kappaletta grant speksejä per käyttäjä. Menee vaikeaksi.
Etkä sittenkään pysty tekemään oikeustarkistusta esim. jonkun kentän arvon tai arvojoukon mukaisesti. Tyypillinen tapaus olisi käyttäjän pääsyn rajoittaminen tiettyihin projekteihin tai sinunb tapauksessasi tiettyihin tileihin tai tilityyppeihin.
Prosarillahan voit päättää myös mitä yksittäisiä enttiä alautetaan käyttäjälle esim roolin tms mukaisesti. Pientä suoritusaikapenalttia pukkaa, mutta ellei käyttäjiä ja hakuja ole aivan isosti ei pitäisi tuonkaan olla ongelma.
TUo IBAN viritys menee prosareilla helpoimmin kun voit rakentaa taulun valintaprosarille (esim. pankitili_select) sellaisen logiikan kuin haluat.
Pankkitili-tauluun joudut joka tapauksessa laittamaan sekä tilinumero- että IBAN-kentät ellet sitten rakennna IBAN koodia select lauseessa dynaamisesti tilinumeron perusteella.
"on irrallinen objektikohtaisista oikeuksista.
Voi aivan hyvin olla oikeus kirjautua mutta ei tehdä mitään muuta kuin suorittaa prosareita.
ILman prosaritekniikkaa joudut granttaamaan jokaisen taulun select, update, delete ja insert oikeuden jokaiselle käyttäjälle erikseen ja ylläpitämään N kappaletta grant speksejä per käyttäjä. Menee vaikeaksi. "
No eipä se nyt niin hankalaksi mennyt. Avain sanat oli mysql.user taulu sekä GRANT.
Jos yrität johonki, niin MySQL palauttaa virheilmon "access denied".
Et pääse tekee mitään. Mutta kyllä tohon hienosäätöön saisi kulumaan aikaa jos haluis vaikka kaikki GUI objektit harmaaksi jne...
Mutta sen takia voi tehdä usergroups taulun tai KOVAKOODAA ne jos tietää, että ryhmiä ei tule kun muutamat hassut.
#define SELECT 0x01
#define UPDATE 0x02
#define INSERT 0x04
unsigned BYTE securitylevel = 0;
securitylevel = securitylevel|SELECT;
securitylevel = securitylevel|UPDATE;
jne...
Mutta joo nyt vodkaa naamaan.
Johan oli vaikeasti löydettävissä. Nyt tuntuu jotenki nöyrältä.
Vaikka gooletin mitä ihmeellisempiä comboja niin ei tullut tulosta, lopulta kumminkin sokea reettakin löysi etsimänsä.
12.4.1. Account Management Statements
http://dev.mysql.com/doc/refman/5.1/en/account-management-sql.html