按照我的理解,策略的执行并非如你所说的: "当用户select表test时,就会先执行包myP里的策略函数select_limit,把策略函数里的返回值作为where子句追加到用户的SQL后,再执行合成后的SQL语句。"当用户SELECT表TEST时,系统会先执行包MYP里的策略函数SELECT_LIMIT,然后把表TEST用一个VIEW来取代,该VIEW是SELECT * FROM TEST WHERE...,WHERE条件就是策略函数返回的值,然后再对该VIEW进行SELECT操作. 虽然从结果来说是一样的,但实质意义并不同.所以没有必要预先知道用户执行的SQL语句.不知道如何抓取用户提交的SQL语句.虽然可以用SQL_TRACEL或者V$SQL来跟踪.
同意:KingSunSha(弱水三千) 的说法.
KingSunSha(弱水三千) 兄弟,谢了! Oracle的一个策略可以映射多个表,我可以编一个策略函数,在策略函数里调用我编写的Java程序。如果有多个表,我得写多个策略函数,并且写多个Java程序,并且假如客户新添加了表,就需要添加新的策略函数和Java程序:那样岂不累死? 我的设想是:我编一个策略(顶多四个:select,insert,update,delete),将这个策略映射到多个表上,在策略函数里调用我编写的Java程序进行统一处理(我要知道对哪个表进行了什么操作,比如:select * from test where id=007,而表test的007纪录他可能没权限select)。 假如原来他的SQL语句为:select * from test where id=007,策略函数里我调用Java程序分析他无权限,策略函数我"return '1=2';",那么SQL语句就变为:select * from test where (id=007 ) and '1=2';由于1=2不成立,这样就查不到任何数据;否则,我给他"return '1=1';",他就能查到数据了。 我做的东西涉及到高级机密,所以得这样控制。
兄弟,谢了!!!
"当用户select表test时,就会先执行包myP里的策略函数select_limit,把策略函数里的返回值作为where子句追加到用户的SQL后,再执行合成后的SQL语句。"当用户SELECT表TEST时,系统会先执行包MYP里的策略函数SELECT_LIMIT,然后把表TEST用一个VIEW来取代,该VIEW是SELECT * FROM TEST WHERE...,WHERE条件就是策略函数返回的值,然后再对该VIEW进行SELECT操作. 虽然从结果来说是一样的,但实质意义并不同.所以没有必要预先知道用户执行的SQL语句.不知道如何抓取用户提交的SQL语句.虽然可以用SQL_TRACEL或者V$SQL来跟踪.
兄弟,谢了!
Oracle的一个策略可以映射多个表,我可以编一个策略函数,在策略函数里调用我编写的Java程序。如果有多个表,我得写多个策略函数,并且写多个Java程序,并且假如客户新添加了表,就需要添加新的策略函数和Java程序:那样岂不累死?
我的设想是:我编一个策略(顶多四个:select,insert,update,delete),将这个策略映射到多个表上,在策略函数里调用我编写的Java程序进行统一处理(我要知道对哪个表进行了什么操作,比如:select * from test where id=007,而表test的007纪录他可能没权限select)。
假如原来他的SQL语句为:select * from test where id=007,策略函数里我调用Java程序分析他无权限,策略函数我"return '1=2';",那么SQL语句就变为:select * from test where (id=007 ) and '1=2';由于1=2不成立,这样就查不到任何数据;否则,我给他"return '1=1';",他就能查到数据了。
我做的东西涉及到高级机密,所以得这样控制。
编写的不对,select操作总提示策略函数错误,然后就不往下执行了,尽管表里有数据。我把策略删除,select操作就可以照常执行了。
应该和where条件本身无关吧,你不过是在where中追加一个条件而已但对于同一个数据库用户,是否不论在哪里登陆近来其权限都一样?
还是说要根据session信息来判定?如果相同数据库用户始终具有相同权限
那么,这个问题处理起来就简单的多,当然你也可以利用dbms_rls.add_policy 来实现调用者权限,这样同样一个包可以被不同的用户使用当然,通过视图,同义词等也可以实现功能。
甚至,根据视图访问数据库,那视图中的一个字段用函数代替,而函数使用pragma可以执行自治事务,这样就可以控制oracle用户的查询操作。并可追踪查询用户记录