Java + Hibernate: zarządzanie userami

Witam

Tworzę aplikację bazodanową MySQL za pomocą Hibernate`a. Zarządzanie userami odbywa się na poziomie bazy danych (DDL, bez tabeli users).
Przy wywołaniu tej linii:

            String newQuery = "create user '" + username + "'@'localhost' identified by 'pass';";
            session.createQuery(newQuery);

Hibernate wywala taki exception:

org.hibernate.QueryException: unexpected char: '@' [create user '" + username + "'@'localhost' identified by 'pass';]
        at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:204)
        at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:111)

Przy użyciu metody createSQLQuery wyjątku nie ma, z tym że user nie jest tworzony...
Czy ktoś doświadczony z hibernate mógłby pomoc? Dzięki wielkie

createQuery tworzy zapytanie HQL, jezyka bazujacego na SQL z wstawkami obiektowymi.
Swoja droga 'insert into...' to nie jest query (SQL) tylko jak sam zauwazyles DDL.

Ale po co uzywasz Hibernate jak piszesz sam inserty? W HB robisz to mniej wiecej tak:
User u = new User(username, password);
session.saveOrUpdate(u);

Przy czym to uzywa osobnej tabeli z userami, specyficznej dla aplikacji. Ten Twoj DDL wiaze aplikacje do bazy danych (MySQL?)

DDL juz w trakcie dzialania aplikacji Hibernate to zly pomysl - ani to transakcyjne, ani Hibernate nie bedzie wiedzial co z takim userem zrobic. Jak tworzysz aplikacje Hibernate to przeciez podajesz usera na starcie (albo w konfigu, albo jakos inaczej) jaki user ma byc uzywany.

jambalaya napisał(a)

createQuery tworzy zapytanie HQL, jezyka bazujacego na SQL z wstawkami obiektowymi.
Przy czym to uzywa osobnej tabeli z userami, specyficznej dla aplikacji. Ten Twoj DDL wiaze aplikacje do bazy danych (MySQL?)

DDL juz w trakcie dzialania aplikacji Hibernate to zly pomysl - ani to transakcyjne, ani Hibernate nie bedzie wiedzial co z takim userem zrobic. Jak tworzysz aplikacje Hibernate to przeciez podajesz usera na starcie (albo w konfigu, albo jakos inaczej) jaki user ma byc uzywany.

Tak jak pisałem wyżej stworzenie użytkownika poprzez dodanie rekordu do tabeli users odpada bo taka tabela nie istnieje (i istnieć nie może, aplikacja jest silnie nastawiona na bezpieczeństwo więc logowanie na roota itd odpada, użytkownicy są zdefiniowani poprzez DDL).

Co twojego ostatniego zdania to przecież nie jest zabronione, aby zalogowany na dane z pliku konfiguracyjnego .xml`a user tworzył innych użytkowników?

Oczywiscie ze nie jest zabronione; pytanie tylko jak taki nowy bazodanowy user ma byc wykorzystany przez juz dzialajaca aplikacje.

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html

createSqlQuery.

aplikacja nastawiona na bezpieczeństwo -> mam nadzieję że "eskejpujesz" to zapytanie, bo z reguły takie ręczne sklejanie zapytań to sztandarowy przykład sql injection.

hmm tak sobie pomyślałem, skoro aplikacja nastawiona na bezpieczeństwo, to user który tworzy połączenie z bazą powinien posiadać jak najmniej uprawnień, w Twoim przypadku ma uprawnienia do tworzenia nowych userów? Dla Mnie to jest dziwne:P

jambalaya napisał(a)

Oczywiscie ze nie jest zabronione; pytanie tylko jak taki nowy bazodanowy user ma byc wykorzystany przez juz dzialajaca aplikacje.

Dlaczego nie miałby być? Przy tworzeniu konfiguracji wstawiam mu do .xml`a podane przez usera dane do logowania i działa.

co do createSQLQuery to problem polega na tym że owszem, exception nie leci ale zwykła fraza tworzenia użytkownika go nie tworzy... tak jakby nigdy nie była wykonana.

Otoz jak tworzysz usera i chcesz aby on byl uzywany przez aplikacje, to musisz wylaczyc serwer / undeploy aplikacji, zmienic konfiguracje, wlaczyc serwer / deploy. Jak dla mnie smieszne / bardzo dziwne. Poza tym co, dla kazdego usera bedziesz startowac aplikacje od nowa? I tak jednorazowo tylko 1 user moze byc przez HB uzywany, co z pozostalymi?
Nie czaje co chcesz osiagnac, ale tak sie tego nie robi ;d

hehe może być używanych więcej userów -> wystarczy tworzyć nowe sessionFactory lub inne dziwadła. Więc się owszem sie da, ale sensu ma to mało:P

No tak, mozna, ale te session factory tez uzywaja plikow conf w ktorych sa ci nowi userzy. Czyli ktos musi podczas dodawania usera dodawac tez nowy konfig albo cos. Session factory chyba moze tez pobierac dodatkowe ustawienia. Ale jak to ma dzialac to nie czaje.

No to ok, załóżmy że rozwiązanie jest totalnie bez sensu.
Więc sugerujecie stworzenie tabeli users, i z niej wyciągac uprawnienia dla usera?
Jak w takim razie logować się do bazy na samym początku? bo rozumiem że user na którego zaloguję się przy uruchomieniu aplikacji już się nie zmieni?

Masz usera hibernatowego, jednego, ktory moze czytac dany schemat, zapisywac do niego cos, robic selecty itp.
Samo bezpieczenstwo wcale nie musi byc robione na poziomie bazy danych - mozesz podlaczyc LDAP, jakies Active Directory windowsowe (tak wiem ze to jest implementacja LDAP miedzy innymi, ale jednak rozni sie), lub nawet lokalne konta uzytkownikow. PAM, Kerberos czy inne cuda wianki. Albo mozesz miec wlasnie tabele z userami. Fajnie jest to rozwiazane w tomcacie, gdzie masz tzw. user realms, klasa Real, ktore maja rozne implementacje (LDAP, users, db, file) i konfigurujesz jakis realm i jest uzywany przez tomcata. Ty tylko definiujesz grupy i ich uprawnienia, a gdy dodawany jest user dodajesz go do jakiejs grupy / roli.
Zajrzyj moze do spring security czy cos, jest duzo gotowych rozwiazan.

Oki załóżmy że tworzę tabelę z userami.
I jakie prawa powinien mieć user który wyląduje w pliku konfiguracyjnym .xml Hibernate`a?
Tylko do tej tabeli z userami? To po weryfikacji użytkownika i tak będzie musiało nastąpić przelogowanie żeby nowo zalogowany miał odpowiednie prawa do bazy danych...
A jeśli nie tylko do tabeli z userami - czyli zakładam ze loguje sie jako user majacy prawa do wszystkich tabel- to wyciągniete uprawnienia z tabeli users określają mi które np GUI mam ukryć żeby nie miał dostepu do pewnych opcji? I realizuję uprawnienia po prostu sztucznie, bo nie zmieniam zalogowanego użytkownika do bazy danych...
Dzięki wielkie za pomoc

Ten user hb musi miec prawa do dodawania usuwania itp w calym schemacie, naturalnie tylko do tabel ktore tego wymagaja. Same uprawnienia userow sa okreslane dynamicznie przez aplikacje w czasie jej dzialania.

Czyli podsumowując: uruchamiając aplikację loguję się 1 raz do bazy danych i to co póxniej na niej będe wykonywał a czego mi nie będzie wolno będę rozwiązywał na poziomie aplikacji/GUI nie bazy danych?

Tak. Zauwaz, ze korzystajac z bezpieczenstwa bazy danych mozesz wplywac tylko na to, co kto zapisuje odczytuje tworzy - czyli tylko i wylacznie na bazodanowe operacje. Twoja aplikacja ma jednak wiele wiecej warstw ktore musisz oprogramowac: np dana stronka moze byc widziana przez admina, a nie przez byle kogo. Listy plac moga byc wyswietlone przez ksiegowych, ale nie przez szarego usera - to taki przyklad. Aby to osiagnac, musisz i tak zrobic wlasne bezpieczenstwo, poza baza danych - wiec zrob to raz, ale konsekwentnie.
Oczywiscie, mozesz uzyc juz gotowych bilbliotek itp, nikt nie kaze tego robic recznie. Kilka mozliwosci padlo wczesniej.