A blog about Application Express and Oracle related topics.
The EA1 for APEX 4.1 is out, so people are trying to use what we built for the last months, hopefully with success. Building Authorization Plugins was one of my tasks. The new plugin architecture allows developers to build authorizations in a declarative way, instead of copying and pasting SQL and PL/SQL code. Here’s a small walkthrough on how to make use of it. The example plugin can be used for authorizations using the built-in user and group management of APEX.
function is_authorized ( p_authorization in apex_plugin.t_authorization, p_plugin in apex_plugin.t_plugin ) return apex_plugin.t_authorization_exec_result is l_group varchar2(4000) := p_authorization.attribute_01; l_count number; l_result apex_plugin.t_authorization_exec_result; begin select count(*) into l_count from apex_workspace_group_users where user_name = p_authorization.username and group_name = l_group; l_result.is_authorized := l_count > 0; return l_result; end is_authorized;
The plugin has been created. Now we define an authorization based on the plugin.
To test our authorization scheme, we have to create users and assign groups to them, then apply the authorization to some pages, regions or items. But I’m sure you already know how to do that ;-)
In APEX 4.0, you would have probably built the authorization scheme using an exists SQL query. And copied the query to every other group authorization scheme (Is Sales, Is Accounting, …), which is harder to maintain. Plugins can help to encapsulate the authorization code in one place and prevent mistakes.
Because EA1 users do not have easy access to APEX package specs, here are the data type declarations for authorization plugins:
create or replace package wwv_flow_plugin as ... type t_authorization is record ( id number, -- internal id of authorization scheme name varchar2(255), -- authorization scheme's name (see step 17) username varchar2(255), -- current user's name attribute_01 varchar2(32767), -- plugin attribute values 1 to 15 attribute_02 varchar2(32767), attribute_03 varchar2(32767), attribute_04 varchar2(32767), attribute_05 varchar2(32767), attribute_06 varchar2(32767), attribute_07 varchar2(32767), attribute_08 varchar2(32767), attribute_09 varchar2(32767), attribute_10 varchar2(32767), attribute_11 varchar2(32767), attribute_12 varchar2(32767), attribute_13 varchar2(32767), attribute_14 varchar2(32767), attribute_15 varchar2(32767) ); type t_authorization_exec_result is record ( is_authorized boolean ); -- set to true if authorization succeeds ... end wwv_flow_plugin;
The 2nd type might seem excessive, but we prefer records, so extensions in later releases will not change function signatures.
There was an inconsistency in the record types t_authorization and t_authentication that we could fix before the 4.1 release. Both now contain an attribute username, I renamed t_authorization‘s user_name. Thanks go to Scott Spendolini for finding that issue.