Генерация ID сессии средствами Oracle
 

Господа, планирую REST-сервис, поддерживающий аутентификацию. Т.е. ты ему логин/пароль, а он тебе в ответ уникальный идентификатор сессии.
При этом хотелось бы этот самый идентификатор сессии генерировать средствами Oracle RDBMS, с которым REST-сервис будет активно работать.
Вопрос в следующем:
Как наиболее правильно генерировать такой идентификатор, дабы обеспечить уникальность и надежность? Интересует реализация именно внутри Оракла. Как это делается на том же .NET я в курсе.

[url]http://docs.oracle.com/cd/E11882_01/server.112/e17118/functions187.htm[/url]

но на надежность он не тянет

[b]wayerr[/b]
тоже смотрел на эту функцию, но хочется придумать более корректный способ генерации.

Какой сервис будет statefull, stateaware, durable? ну и развертываться будет как сингл или кластер?

[b]simoncat[/b]
Дык, REST по сути своей stateless (поправь, если ошибаюсь).
Потенциально развертываться будет на кластере - именно поэтому хочу сессии хранить в БД и там же генерировать.

Но как это все относится к моему вопросу про генерацию ID сессии средствами Oracle? :)

>Потенциально развертываться будет на кластере - именно поэтому хочу сессии хранить в БД и там же генерировать.

А бд кластеризоваться не будет, это меня всегда веселит в распределенных веб приложениях\сервисах.

4 Можно сварганить сервис так, что он будет не stateless, однако API будет в стиле REST.

Если будет потенциально кластер из нескольких узлов, на каждом из которых развернут твой сервис, а балансировка будет per request, погляди в сторону такого решения:

1) не генерируем session id в базе, генерируем в сервисе (на всех узлах один и тот же сервис, потому алгоритм одинаков.
2) сервис получив вначале login/password лезет в credential storage (какой он у тебя будет не столь важно), пытается найти там запись о пользователе.
3) если (2) удачно, генерирует session id таким образом user_name+session_check_time+login_ip_address, шифрует эту строку симметричным алгоритмом (ключи знают только сервисы на узлах, одни и те же на всех узлах) и абракадабру session id отсылает клиенту в HTTP headers
4) дальше при HTTP request к сервису указываешь сервису session id в HTTP headers. Запрос будет перенаправлен сервису на каком-то узле (не важно каком). Сервис расшифровывает session id. Получает user_name. Который будет использовать для авторизации, выборок и т. п..
5) на каждом реквесте можно выполнять проверки session id:
5a) Истекла ли сессия current_time - session_check_time < session_life_time. При выполнении такой проверки, если сессия не истекла, обновляем session id изменив в нем session_check_time и отправив в заголовке ответа обновленный session id. Он должен использоваться далее...
5б) сравнение login_ip_address с request ip address на случай кражи,
5в) напихать в session id все что нужно для ужесточения проверок...

У этого подхода недостатки, как минисум: нету кнопки logout, нет контроля количества одновременных сессий.

Достоинства: минимизация ебли бд.

Писал с трубы, так что, если что...

5 может у топикстартера шардинг будет или дорогой oracle race.

Для всяких сессионных дел, может оказаться выгодным использование какогр-нибудь nosql..

[em]5-wayerr >А бд кластеризоваться не будет, это меня всегда веселит в распределенных веб приложениях\сервисах[/em]
Сам же знаешь причины. Цена вопроса сильно возрастает с тем же самым RAC.

6-simoncat >
Твой алгоритм прочитал. Сейчас проснусь - и вчитаюсь получше. Но пока что у меня как минимум одно возражение:
Неоходимо при каждом запросе дешифровать и шифровать обратно, ведь нужно будет обновлять время session_lifetime. Не многовато ли процессорных затрат...

9 все зависит от требованиям к безопасности.

а) можно не шифровать
б) можно не продлять, оставив сессию бесконечной
в) можно не шифровать, но натянуть ssl

и т. п..

просто, на мой взгляд (ни на что не претендую) лучше не генерить это в бд, я так понял ты захотел хранить в ней сессии, чтобы бд выступала в роли эдакого shared storage. там появится следом за session id какая-нибудь полезная тебе метаинформация (например управление временем жизни сессии) и следом появятся update'ы на каждый чих, если хочешь так, то пусть он будет in memory nosql (у тебя же я так понял никакого durable сервиса не планируется). можно доработать мой способ под использование nosql, тогда не прийдется обновлять session id, появится возможность контролировать количество одновременных сессий, кнопка logout...

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

9-CPU > Сам же знаешь причины. Цена вопроса сильно возрастает с тем же самым RAC.

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

Кстати если твое приложение без сессии ну никак не может, и на принципы REST (а там сессионное состояние хранится на клиенте) положить, то распределенную сессию всеравно придется ваять не на субд (как вариант костыль: sticky-sessions).

Добрый день, потскажыте пожалуйста как угадать цыфру рулетку на гидре

Программа рашефровка хеша DM5