三层数据库结构中的身份验证问题（SQL 7.0+delphi 5.0)(150分)

mycwcgr · 2001-01-01

在三层数据库结构中，后台服务器使用SQL 7.0, 可以加入一个应用服务器，应用服务器
只允许系统管理员登录，在应用服务器中加入有关身份验证的程序段，根据登录用户的情
况，决定该用户能执行什么操作。这样是不是就能够不用在SQL 7.0中为每个用户建立一个登
录名，为每个用户设置权限。如果真是这样的话，SQL 7.0中的复杂的表级权限（如，某些
表，只允许某些用户使用SELECT语句。。）是不是有些多余？因为这些在应用服务器中都能
用编程的方法解决，而应用服务器只能由系统管理登录，从而防止其它用户非法修改？

不夜城 · 2001-01-01

兄弟, 如果对每一个使用你程序的用户都在数据库里分配一个帐户的话,
你怎么来实现安全控制.
除非你给每一个用户都赋予类似于DBA用户的权限,再自己的程序里从一个
较高的层面上重新授权, 甲/乙/丙可以用哪些模块/表/字段[取决于你的程序是怎么写的]

mycwcgr · 2001-01-01

在SQL 7.0中，我的数据库中有一个用户表，有每个用户的用户名和口令，
在应用服务器中，根据客户端提供的用户名，在应用服务器上来判断它要求的SQL语句
是否可以允许，或者根据客户端提供的用户名，返回一组参数，使客户端界面上的有关
BUTTON是ENABLED OR DISENABLED

不夜城 · 2001-01-01

对不起说错了.
应该是:
兄弟, 如果 --不-- 对每一个使用你程序的用户都在数据库里分配一个帐户的话,
你怎么来实现安全控制.

不夜城 · 2001-01-01

在SQL 7.0中，我的数据库中有一个用户表，有每个用户的用户名和口令，
在应用服务器中，根据客户端提供的用户名，在应用服务器上来判断它要求的SQL语句
是否可以允许

--用户到底是在用你的程序还是直接敲SQL

或者根据客户端提供的用户名，返回一组参数，使客户端界面上的有关
BUTTON是ENABLED OR DISENABLED

--用户首先是可以访问这些客户端界面所用到的表视图什么的,
然后你又在自己程序里做了一次权限封装.

mycwcgr · 2001-01-01

我在我的数据库中的一个表中为每个用户分配一个账户，此表只有我能修改，
应用服务器只能我LOGIN IN ，其它用户只能在客户端使用应用服务器与数据库相联系，
应用服务器根据登录的用户名决定它能用什么操作！！！

不夜城 · 2001-01-01

还是我说的那个意思啊.

其它用户只能在客户端使用应用服务器与数据库相联系，
应用服务器根据登录的用户名决定它能用什么操作！！！

--用户首先肯定是可以访问这些客户端界面所用到的表视图什么的,
然后你又在自己程序里做了一次权限封装.

mycwcgr · 2001-01-01

用户表是在我的数据库中的表中输入的，它有些特征值，如职务，职称，用户名，口令等等，
根据从客户端的的登录的用户名、口令，在应用服务器上查询后端数据库用户表中是否存在
，如果存在，再根据此人的职务分配权限！

不夜城 · 2001-01-01

不说了.
我要说还是重复那几句话.
此贴可以终止了.

mycwcgr · 2001-01-02

to 不夜城:
您可能是对的，因为在客户端，在连接上应用服务器时是以管理员身份登录的，
而且管理员的用户名和口令是固化在客户端程序中的，虽然可以进行一些加密处理
但并不是一个安全的方法，在登录成功之后，才在我的数据库中的一个表上验证
用户名和口令是否在用户表中存在，这是一个假登录。

不夜城 · 2001-01-02

估计你就是这么搞的.

再告诉你一个方法不过有点烦.[我也不这么搞]

创建每一个用户时,在数据里给对应创建一个用户, 然后对数据库对象进行合适授权.

用户的帐号口令都可以再加一把密.

不过你要提供容易使用的系统管理员界面方便他干这个事.

同时对系统分析设计要求也提高了.

Another_eYes · 2001-01-02

我同意mycwcgr的观点, 事实上我也是这么做的. 应用服务器用SA登录SQL SERVER
然后所有客户端操作都由应用服务器检验权限并判断是否违例. 应用服务器控制的依据
是SQL SERVER中一个自建立的用户表和一个用户登录记录表, 其中都包含有用户操作
权限字段(一个varbinary字段, 每字节代表一个操作逻辑的读写权), 客户端的所有读写数
据操作都由应用服务器进行判断. 这样我可以做到记录级的权限控制(其实就是所有表都
加上了一个权限字段(Int型)指明允许具备多少读写级别的用户能够读取/修改/添加/删除
该记录). 至于控制用户操作, 实现起来就更简单了, 只要跟踪相关事件就行了, 读操作时
由应用服务器根据用户权限生成过滤条件SQL附加在用户请求后发往数据库服务器, 写
操作时则判断每条记录的权限以决定是否将修改提交到数据库服务器.
唯一增加的操作在客户端, 客户端所有请求都需要额外传送一个登录ID(在用户登录程序
登录成功后由应用服务器返回, 为了安全性考虑, 我用了个GUID)以供应用服务器进行权
限判断.
这样做的好处是可以绕过SQL SERVER烦琐的安全设置而提供相同的安全级别(一个极
端: 您甚至可以由应用服务器生成一个随机的SA口令, 这样, 除了您的程序外, 任何人,
包括系统管理员都无法操作SQL SERVER了).

mycwcgr · 2001-01-14

还有高见？

mycwcgr · 2001-03-02

多人接受答案了。

三层数据库结构中的身份验证问题（SQL 7.0+delphi 5.0)(150分)

mycwcgr

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

不夜城

Unregistered / Unconfirmed

Another_eYes

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

mycwcgr

Unregistered / Unconfirmed

Similar threads