GlassFish JDBC 领域组成员资格

发布于 2024-11-26 14:39:55 字数 575 浏览 0 评论 0原文

我一直忙于在 GlassFish 3.1 上设置身份验证,特别是 JDBC 领域。我一直在假设以下情况下进行操作:

  • “User”表包含登录名(“email_address”)和密码(“password”)
  • “Group”表包含组名称列表(“name”)
  • A “User_Group " 表将用户和组进行匹配。

然而,我无法配置“User_Group”表,所以我想知道服务器如何能够将用户与组进行匹配。不用说它不起作用。然而,仔细检查表明:

  • “User”表包含登录名(“email_address”)和密码(“password”)
  • “Group”表包含登录名(“email_address”)作为主键,以及单列(“组”)中以逗号分隔的组名称列表(“管理员,用户”),

这是否正确?如果是,为什么要费力创建单独的“组”表?既然看起来每次登录只能有一个组列表(“email_address”),那么难道不是像简单地将名为“组”的列添加到“用户”表并完全丢弃“组”表一样简单吗?

谢谢!

I have been busy setting up authentication, a JDBC realm in particular, on GlassFish 3.1. I have been operating under the assumption that:

  • The "User" table contains the login name ("email_address") and the password ("password")
  • The "Group" table contains a list of group names ("name")
  • A "User_Group" table matches users and groups up.

Nowhere was I able to configure the "User_Group" table however so I was left wondering how the server would ever be able to match users up to groups. Needless to say it did not work. Closer inspection however suggests that:

  • The "User" table contains the login name ("email_address") and the password ("password")
  • The "Group" table contains the login name ("email_address") as primary key, and a comma-separated list of group names ("Administrator,User") in a single column ("groups")

Is this correct and, if so, why go through the trouble of creating a separate "Group" table? Since it seems you can have only one grouplist per login ("email_address") wouldn't it be just as easy as to simply add a column called "groups" to the "User" table and discard the "Group" table altogether?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

葬心 2024-12-03 14:39:55

我不确定您按照什么材料来配置 JDBC 领域,但它似乎不完整或不正确。以下是我用来配置 JDBC 领域的配置的描述。


数据库结构(作为 DDL 语句):

USERS 表

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

--//@UNDO

DROP TABLE USERS;

GROUPS 表

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;

来自域的 Glassfish JDBCRealm 配置片段.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 类):

密码查询,用户 ID 为从 DigestLoginModule 传递的参数:

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

组查询,用户 ID 作为参数传递:

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

当您考虑第二个查询的结构时,很明显组表必须包含用户映射到组Id的Id(这会导致映射到多个组的用户的组数据重复),或者组表必须是将用户映射到组的联接表。

I'm not sure what material you've followed to configure the JDBC realm, but it appear to be incomplete or incorrect. Following is a description of the configuration I've used to configure the JDBC realm.


The database structure (as DDL statements):

The USERS table

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

--//@UNDO

DROP TABLE USERS;

The GROUPS table

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

--//@UNDO

DROP TABLE GROUPS;

The USERS_GROUPS join table

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

--//@UNDO

DROP TABLE USERS_GROUPS;

The Glassfish JDBCRealm configuration snippet from 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>

Note, the group-name-column attribute having a value of GROUPID, which maps to the GROUPID column of the join table USERS_GROUPS and not the group table GROUPS. This is because the JDBCRealm issues the following SQL statements (if you decompile the com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm class):

The password query, with the user Id being the parameter that is passed from the DigestLoginModule:

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

The group query, with the user Id being passed as the parameter:

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

When you consider the second query's structure, it is quite obvious that the group Table must either contain the user Id mapped to a group Id (which leads to duplication of group data for users mapped to multiple groups), or that the group Table must be the join table that maps users to groups.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文