Есть Weblogic сервер на котором крутится приложение на JSF+ADF. Авторизация и доступ по логину и паролю через пользователей в СУБД через ADF Security+Weblogic Authenticator.

Необходимо фиксировать пользователей apllication-а в СУБД. Каким образом организовать? Пока что вычитал механизм передачи через контекст с глобальным доступом в Oracle. Для чего можно использовать DBMS_SESSION пакет (SET_IDENTIFIER, SET_CONTEXT), соответственно с разным client_id.

Вопрос на каком этапе использовать:
- перед внесением изменений в базу(каким образом передать в контекст);
- во время логона (минус в том что могут зайти несколько пользователей аппликейшна и пул соединений может затереть предыдущий контекст);

Есть ли другой механизм наподобие функции V в апексе или USER переменной в СУБД?

Спасибо

just_vladimir,

Спасибо за ответ.
А каким образом? Не будет ли параллельных запросов на запрос соединения?

Petro123,

Да в СУБД есть хранимая процедура которая вызывается на стороне веб сервера, которая устанавливает аттрибуты в глобальном контексте для конкретного юзера, идентификатором наверное будет сешн айди соединения, далее аттрибуты айпи адрес, юзернейм, роли, время создания соединения и прочее.

Таким образом при изменении каких либо данных в таблице триггер будет считывать логин и прочие аттрибуты вносящего имзенения пользователя через идентификатор сешшн айди. Но меня интересует вопрос в какой момент вызывать процедуру для установки данных в контексте?

Или необходимо во всех табличках держать дополнительное поле с сешшн айди? При изменении данных загонять туда на стороне веб сервера данные?

P.S.: Насчет предложения прозрачного проксирования, это не подходит т.к. не хотелось бы держать всех пользователей апплик в качестве пользователей СУБД. Неудобство администрирования.

Petro123,

автору меня такая схема работает без пула. Т.е. если нет пула и каждый пользователь получает свой коннект пока не отработает и не выйдет.Т.е. это длинные транзакции для бизнес приложения.

А загрузка СУБД?

авторЕсли публичный сервер, то там обезличенные пользователи ходят под одной схемой оракла (одним логином).
Ну и естьсмешанная схема.

О это интересно. А можно поподробнее как реализовано?

авторБез пула? Юзверей не много?
пользователей на начальном этапе 150, потом 200 в течение полугода еще добавятся и т.д. по нарастающей

автори задача какая? Просто логи кто что делал или Запрет действий по ролям?
Тут и логи на каждую транзакцию и запрет действий, на уровне СУБД тоже будет на триггерах.

авторА то, мне кажется ты соединяешь 2 технологии вместе JSF\ADF и ручные Роли через ручной контекст БД.
Да есть такое )))
Роли на сервере приложений будут на уровне адф секьюрити + авторизация доступ на конкретные jsf страницы.
На стороне сервера предполагается второй уровень защиты описанный выше, ну плюс логгирование.

Petro123,
авторнаверно нагрузку имел ввиду? ). Ну конечно не Одноклассники. Но 1K - 10K потянет.
Да, но даже при 2К я думаю PGA всю память съест.

авторСмешивать не очень хорошо.
А вот, про то что ходят под одним, так это ты мне должен рассказывать. это стандарт в Java - Хибер.
Поэтому, с ним определись. Все проекты на нём.

Иначе:
Сервлет{
Conn = GetConnection;
Conn.SetInfo(IP.....)
Conn. поработал
Conn.Close
}

у меня так сайт работает)


Я использую АДФ (Fusion App) а это уже ОРМ. Тут такое не проканает )


авторесли нравится в СУБД, тогда минимум в Хибере...можно без пула.
Если с пулом то найди тему - прокси-ХХХХХХ

Можно поподробнее?

Petro123,

На самом деле хранимка используется только для того чтобы выставить данные в глобальном контексте.

Насчет Proxy Authen она не подходит я изначально писал, в оракле требование, я так понял , чтобы пользователи аплпикейшна были также и пользователями оракла. Разница реализации между использованием прокси аус и использованием пула соединений лишь в том, что в базу пользователь лезет под личной учеткой или под общей. А на стороне БД пользователи в обеих случаях есть и являются пользователями БД.

1.
У Оракла под пользователями понимается Схема (в пику сиквелу).
Т.е. CREATE USER логин пароль создаёт пол-ля.
Дальше они вынуждены работать не совместно, т.к. данные НЕ общие. Их можно обобщить, но тогда надо раздавать права "владельца" всем.

Да конечно никто не спорит. Естественно нужно заводить пользователей (схему), создавать паблики, давать им гранты на текущую схему и т.д.
Т.е. в данном варианте считай, как в сиквеле у каждого своя БД.
схема имелась ввиду наверное)

2. В той ссылке делается вручную в пуле передаётся инфа через контекст.
ИЛИ 2 вариант -
CREATE USER GLOBAL - это корпоративный пользователь.
Проясни про пользователей Оракла исходя из п.п.1
[/quote]

исходя из того что я читал про ксвозную аутентиф, напишу так:
На стороне БД:
create user mark identified by passs
create user natasha identified by passs
alter user mark GRANT CONNECT THROUGH dbuser;
alter user mark GRANT CONNECT THROUGH dbuser;
На стороне вэблоджика соотв-но настраивается секьюрити реалм.
Но этот вариант меня не устраивает вообще.

Нужен 1 пользователь базы со всеми правами селект апдейт делет, и апп пользователи, данные о которых забиваются в глобальном контексте. Повторю вопрос - на какой стадии передавать в контекст данные о пользователе?

Сергей Арсеньев,

А как прикрутить туда информацию на стороне веб приложения и извлечь ее на стороне СУБД?

Petro123,

Спасибо