Членство в GlassFish JDBC Realm Group - PullRequest
Новая
       26

Членство в GlassFish JDBC Realm Group

2 голосов
/ 24 июля 2011

Я был занят настройкой аутентификации, в частности, области JDBC, на GlassFish 3.1.Я работаю в предположении, что:

  • Таблица «Пользователь» содержит имя пользователя («адрес электронной почты») и пароль («пароль»)
  • «Группа»Таблица содержит список имен групп («имя»)
  • Таблица «User_Group» сопоставляет пользователей и группы.

Однако нигде не удалось настроить таблицу «User_Group»поэтому мне было интересно, как сервер сможет сопоставить пользователей с группами.Излишне говорить, что это не сработало.Однако при более тщательном рассмотрении выясняется, что:

  • Таблица «Пользователь» содержит имя для входа («адрес электронной почты») и пароль («пароль»)
  • Таблица «Группа» содержитимя для входа («email_адрес») в качестве первичного ключа и разделенный запятыми список имен групп («Администратор, пользователь») в одном столбце («группы»)

Правильно ли это, и если да, то зачем создавать отдельную таблицу «Группа»?Так как кажется, что вы можете иметь только один групповой список для каждого логина («email_address»), не будет ли так же просто добавить столбец с названием «groups» в таблицу «User» и полностью удалить таблицу «Group»?

Спасибо!

1 Ответ

9 голосов
/ 25 июля 2011

Я не уверен, какой материал вы использовали для настройки области JDBC, но он кажется неполным или неправильным.Ниже приведено описание конфигурации, которую я использовал для настройки области JDBC.

Структура базы данных (в виде операторов DDL):

Таблица USERS 

CREATE TABLE USERS (
        USERID VARCHAR(50) NOT NULL,
        PASSWORD VARCHAR(128) NOT NULL
    );

--//@UNDO

DROP TABLE USERS;

Таблица ГРУПП 

CREATE TABLE GROUPS (
        GROUPID VARCHAR(20) NOT NULL
    );

--//@UNDO

DROP TABLE GROUPS;

Таблица объединения USERS_GROUPS 

CREATE TABLE USERS_GROUPS (
        GROUPID VARCHAR(20) NOT NULL,
        USERID VARCHAR(50) NOT NULL
    );

--//@UNDO

DROP TABLE USERS_GROUPS;

Фрагмент конфигурации JDBCRealm Glassfish из domain.xml: 

    <auth-realm name="MyRealm" classname="com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm">
      <property description="null" name="jaas-context" value="jdbcRealm"></property>
      <property name="encoding" value="Hex"></property>
      <property description="null" name="password-column" value="PASSWORD"></property>
      <property name="datasource-jndi" value="jdbc/myDS"></property>
      <property name="group-table" value="USERS_GROUPS"></property>
      <property name="user-table" value="USERS"></property>
      <property description="null" name="group-name-column" value="GROUPID"></property>
      <property name="digest-algorithm" value="SHA-512"></property>
      <property description="null" name="user-name-column" value="USERID"></property>
    </auth-realm>

Обратите внимание, что атрибут group-name-column имеет значение GROUPID, которое отображается в столбец GROUPID таблицы объединения USERS_GROUPS, а негрупповой стол GROUPS.Это связано с тем, что JDBCRealm выдает следующие операторы SQL (если вы декомпилируете класс com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm):

Запрос пароля, а идентификатор пользователя является параметром, который передается из DigestLoginModule: 

SELECT <passwordColumn> FROM <userTable> WHERE <userNameColumn> = ?

Групповой запрос с идентификатором пользователя, передаваемым в качестве параметра: 

SELECT <groupNameColumn> FROM <groupTable> WHERE <groupTableUserNameColumn> = ?;

Когда вы рассматриваете структуру второго запроса, совершенно очевидно, что таблица Group должна содержать либо сопоставленный идентификатор пользователяк идентификатору группы (что приводит к дублированию данных группы для пользователей, сопоставленных с несколькими группами) или к тому, что таблица группы должна быть таблицей объединения, которая отображает пользователей в группы.

...