Доброго времени суток!

Имеем Application Express 3.2.1.00.10.

Есть схема DBADMIN. Ей дадена роль apex_administrator_role.
Есть воркспейс с id xxx.

Есть такая функция в схеме DBADMIN:

create or replace function lock_user_apex(
username$ in varchar2,
lock$ in number, -- 0 - разблокировать, 1 - заблокировать.
block_reason$ out varchar2
) return number is
Result number(1):=0;
.....
pp_userid number;
begin
block_reason$:='';
WWV_FLOW_API.SET_SECURITY_GROUP_ID(p_security_group_id => xxx);
pp_userid:=apex_util.get_user_id(p_username => username$);
pp_locked:=apex_util.get_account_locked_status(p_user_name => username$);
.........
.........
.........
return(Result);
end lock_user_apex;

Засада в том, что, когда коннектишься к Ораклу под именем dbadmin (владельца функции), эта функция выполняется.
А вот если коннектишься под, скажем, юзером scott (которому, тем не менее, даны права на вызов dbadmin.lock_user_apex, то под ним вылазит такая вот ошибка: unauthorized access (security group package variable not set).
При том, что SET_SECURITY_GROUP_ID отрабатывает (не приводит к ошибке).
А к ошибке приводит строка pp_locked:=apex_util.get_account_locked_status(p_user_name => username$);
А в строке ранее pp_userid:=apex_util.get_user_id(p_username => username$); заметил, что под dbadmin получаем правильный pp_userid, а под scott получаем null.
Я сделал эту функцию и эту схему специально для того, чтобы неадмины (техподдержка) могли управлять юзеровскими эккаунтами. Не хочется юзерам типа скотта давать роль apex_administrator_role и иже с ними.
Может, кто-то мне скажет, что нужно делать в таком случае?
Ведь функция должна вызываться в таком контексте с правами создателя, т.е. схемы dbadmin, а не скотта...
Спасибо, что прочитали)

SvUser,

Все вызывается вне апекса, из дельфовой программы или из пл/скл девелопера.
Просто в предыдущих версиях апекса оно вообще не хотело работать вне апекса, даже с сет_секурити_айди. А в этом появилась роль apex_administrator_role и заработало все вне контекста.
Да, вот только что проверил: если юзеру scott дать роль apex_administrator_role, то, подконнектившись как scott, успешно выполняем процедуру dbadmin.lock_user_apex. А если эту роль у скотта забрать, то вызов этой процедуры вываливается с ошибкой авторизации. Но я спецом для этого и создал схему dbadmin, чтобы роль дать именно ей, а не скотту, а скотту дать право только выполнять процедуру. С просто Ораклом как СУБД такое работает, т.е. dbadmin имеет право блокировать/разблокировать юзера, а скотт не имеет, и тем не менее, он вызывает dbadmin.lock_user и может блокировать/разблокировать. А вот с апексом такое не проходит (((
Что делать?.. В крайнем случае, конечно, дам скотту apex_administrator_role. Но это не выход, он тогда сможет творить че захочет)

Молчит народ... :)
Если кому-то интересно, я нарыл вот что: посмотрел, что это за роль, apex_administrator_role.
Единственное, что есть у этой роли, это право на вызов apex_030200.wwv_flow_instance_admin.
А так как в этом пакете есть такая функция, как, скажем, remove_workspace, то я как-то сильно против, чтобы давать право на этот пакет скотту или техподдержке.

Провел небольшой эксперимент, а именно:
grant apex_administrator_role to scott;
revoke execute on apex_030200.wwv_flow_instance_admin from apex_administrator_role;
Теперь у скотта роль есть, а фактических прав нет :)
Результат: у скотта все работает!! Т.е. скотт может теперь вне среды Апекса, под своим именем спокойно блокировать/разблокировать юзеров воркспейса, и я не боюсь за то, что он что-то глобально напортит в этом воркспейсе или в других.

Отсюда простой как гвоздь вывод:
Апекс тупо проверяет на то, чтобы у юзера, вызывающего, скажем, apex_util.get_account_locked_status или apex_util.lock_account, была роль apex_administrator_role. Если этой роли у юзера нет, самим же Апексом генерится ошибка.
_Даже_ если юзер делает все это через вызов обрамляющего пакета/процедуры, в данном случае через мою dbadmin.lock_user_apex, которая уже сама вызывает apex_util.get_account_locked_status и обладает всеми для этого необходимыми правами, все равно права должны быть именно у того, кто вызывает. Как-то нехорошо это. Получается выполнение с правами вызывающего, а не создателя, как нужно было бы по умолчанию.

Теперь, хоть и проблема решена, как говорится, напильником, путем подпиливания роли apex_administrator_role, я не горю желанием переносить ее на продакшн сервер по той причине, что в последующих версиях апекса, скорее всего, роли apex_administrator_role дадутся еще какие-то глобальные привилегии супер админа, и надо будет подпиливать эту роль по новой, не говоря уже о том, что apex_administrator_role может реально понадобится кому-то неподпиленной.
Т.е. как-то нехорошо, что для управление юзерами воркспейса нужны такие права, которые позволят этот самый воркспейс даже удалить, и вообще рулить всеми остальными воркспейсами, т.е. права мегаадмина.
Быть может, в 4м апексе это подправили, а может, это фича такая. В общем, где-то так.
Если есть соображения - высказывайте. Я думаю, программно рулить юзерами воркспейса, дело очень нужное многим, кто использует Апекс.

SvUser,

Ага, я так понимаю, тут апекс пытаются обмануть, сказав ему, что он работает в среде веб-интерфейса, что ли?.. Создать каку-то среду вызова... Не совсем понял, если честно.
Но у меня проблема была именно в роли, поскольку: дал - заработало, отнял - перестало работать :)
Вообще, я писал не про то, чтобы давать роль до и отнимать ее сразу после, а про то, чтобы у самой роли забрать опасные привилегии, т.к. Апексу не важно, что дано этой роли, а важно лишь то, что роль с таким названием есть у юзера, под которым коннект к БД. Но там коряво, бо в след. версии Апекса этой роли может быть дадено еще что-то опасное, да и кромсать системную роль - это не дело все-таки.
Мне тут подсказали про вот что:
Oracle предлагает такой механизм, как Secure
Application Roles - возможность в открытом сеансе пользователя,
устанавливать ему роль путем запуска в приложении специальной
процедуры, ассоциированной с этой ролью. См. документацию -
http://download.oracle.com/docs/cd/E11882_01/server.112/e10575/tdpsg_privileges.htm#TDPSG30032
http://download.oracle.com/docs/cd/E11882_01/network.112/e16543/app_devs.htm#i1006262
Не читал еще, попробую, может это то, что нужно... Если речь идет о том, чтобы конкретной сессии временно назначить какую-то роль...