Comments on: Standard for Database Development – Getting rid of USER from PL/SQL and SQL – no longer is USER equivalent to End User https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/ Friends of Oracle and Java Wed, 24 Jun 2015 09:59:44 +0000 hourly 1 http://wordpress.org/?v=4.2.2 By: IT-eye Weblog » Oracle Proxy Users https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2423 Sat, 15 Apr 2006 09:49:27 +0000 /?p=777#comment-2423 […] In the Amis Technology corner Lucas jellema is discussing the problem with Oracle’s USER: Standard for Database Development – Getting rid of USER from PL/SQL and SQL – no longer is USER equivalent to End User. Many applications use USER to determine who’s logged on to the database. Security is based on USER and roles. But this only works if every user actually logs in using his own account. […]

]]>
By: Lucas Jellema https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2422 Wed, 14 Sep 2005 14:16:45 +0000 /?p=777#comment-2422 The benefit of using application contexts is twofold: changes in the values are directly picked up. Values in the package variables are only picked up if you enforce that the policy function is called again after a change is made in the values of the package variables. In Oracle 9i, the Policy Function is called only once per session – the first time a query is run on the table or view the policy function is defined against – unless the policy function depends on the SYS_CONTEXT function. In 10g, you can specify for policy functions if they are static, dynamic (invoked every time a query is run) or context sensitive.

The second benefit of using the Application Context over Package Functions is that a reference to an Application Context in a where clause is resolved like a bind-parameter and evaluated only once per query, whereas a package function is called over an over again for every record that is evaluated, even if the function returns the same value for every call.

]]>
By: Eric Slikker https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2421 Wed, 14 Sep 2005 07:18:27 +0000 /?p=777#comment-2421 Instead of using SYS_CONTEXT, I’m using package_variables. This gives me more flexibility.
In a logon trigger, I can fill the ‘Context-user’ and extra ‘context-data’.
I also fill an internal table with RLS-clauses.

Every VPN-definition is set like:

begin
DBMS_RLS.ADD_POLICY (
object_schema => ‘xxx_OWN’,
object_name => ‘COMPANIES’,
policy_name => ‘RLS_COMPANIES’,
function_schema => ‘SYSBEHEER’,
policy_function => ‘SBR$AUTORISATIE.RLS_autorisatie’
);
end;

The function SBR$AUTORISATIE.RLS_autorisatie returns the WHERE-clause for the current user.
This clause can be different for different users. This can be handy for batch-processing.

FUNCTION SBR$AUTORISATIE.RLS_AUTORISATIE
(p_obj_schema VARCHAR2
,p_obj_name VARCHAR2)
RETURN VARCHAR2
IS
t_predicate VARCHAR2(4000) := ‘1=1′;
BEGIN
IF t_rls_aut_tab.exists (p_obj_name)
THEN
t_predicate := t_rls_aut_tab(p_obj_name);
END IF;
RETURN (t_predicate);
END RLS_AUTORISATIE;

By using the extra context-data, I don’t need the USER_column in my tables.
Users can only access companies they’re authorised for:

SELECT *
FROM COMPANIES
WHERE sbr$autorisatie.autorisatie_company (company_code) = sbr.vtrue;

FUNCTION autorisatie_company
(p_company_code VARCHAR2)
RETURN VARCHAR2
IS
t_return sbr.tp_chr%TYPE := sbr.vfalse;
BEGIN
IF t_aut_company_tab.exists (p_company_code)
THEN
t_return := sbr.vtrue;
END IF;
RETURN (t_return);
END autorisatie_company;

For the Batch-usser, the where-clause from the function SBR$AUTORISATIE.RLS_AUTORISATIE results in:

SELECT *
FROM COMPANIES
WHERE 1=1;

Other tables can depend on this authorised comany table:

SELECT*
FROM COMPANY_LOCATIONS CLS
WHERE EXISTS (SELECT 1 FROM COMPANIES CPS WHERE CPS.COMPANY_CODE = CLS.COMPANY_CODE)

And for batch-users the where_clause can be:

SELECT*
FROM COMPANY_LOCATIONS CLS
WHERE 1=1

]]>
By: John Flack https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2420 Tue, 13 Sep 2005 12:51:14 +0000 /?p=777#comment-2420 Good article – I’ve been thinking about the need for alternatives to USER for some time, but hadn’t come up with a solution I
liked. I’m not sure about using an application context however. Shouldn’t this be a database-wide (or even enterprise-wide)
solution? After all, a single user may have access to more than one application. I have a schema called COMMON, with the same
objects and procedures in all of my databases – things that are granted to PUBLIC with PUBLIC synonyms. Maybe the identity
context should be part of COMMON?

]]>
By: Oded M https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2419 Tue, 13 Sep 2005 07:06:01 +0000 /?p=777#comment-2419 didnt used proxy user for a long time now, but if i remember correctly USER will give the proxy user name. am I wrong?

]]>
By: Lucas https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2418 Tue, 13 Sep 2005 07:00:13 +0000 /?p=777#comment-2418 Review by Pete Finnigan on http://www.petefinnigan.com/weblog/archives/00000549.htm
09/12/2005: “Amis talks about the need to remove USER from PL/SQL and SQL code”

I saw a great article on the Amis blog a few days ago and made a note to have a look and talk about it here. The article is written by Lucas Jellema and is titled ” Standard for Database….[Read More]

I saw a great article on the Amis blog a few days ago and made a note to have a look and talk about it here. The article is written by Lucas Jellema and is titled “Standard for Database Development – Getting rid of USER from PL/SQL and SQL – no longer is USER equivalent to End User”. This is a great article that talks about the need to get rid of the USER pseudo function from older code written in the days when all database users had their own database account and using the function did return the correct user. This was in the days before proxy users and connection pooling. Lucas starts with the reasons USER was used and the implications of using it now and why it should be removed and the fact that he is saying it shouldn’t be removed in all cases. Lucas goes on to show some examples of a home grown application user table and also a VPD example. He goes on to give examples of how the user might be set and the issues of application servers, middle tiers and logon triggers. Lucas also talks about the fact that the use of USER translates to a select from dual and how this has improved in 10g.

Great paper and well worth a read.

]]>
By: ronald https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2417 Fri, 09 Sep 2005 05:36:07 +0000 /?p=777#comment-2417 Very clear exercise!

]]>
By: Scott P https://technology.amis.nl/2005/09/08/standard-for-database-development-getting-rid-of-user-from-plsql-and-sql-no-longer-is-user-equivalent-to-end-user/#comment-2416 Thu, 08 Sep 2005 15:47:26 +0000 /?p=777#comment-2416 Great article. Just yesterday, I worked on this in an application of mine. My need was for archiving/journaling changes to a table. I sought a different approach that does not rely on the application to set the context as I wanted to capture changes being done with other end user tools. (sql plus, toad etc.) I chose to grab osuser and module from v$context and use that instead. It is in testing now, so I am not sure if it will work in all situations, but so far, so good.

]]>