JoFanALOTE... а в таблице структуры типа "user", "password" ...

Пароли надеюсь не в открытом виде хранятся ? )

Вариант работы: пользователь конектится к БД под общедоступным логином и "регистрируется" через вызов ХП - в случаи неудачи - разрыв соединения со стороны сервера. При успешной регистрации - выдается сессионый ключ - его нужно предоставлять для доступа к данным. Если нужно, выполнять шифрование канала средствами БД.

При наличии поддержки ролей в СУБД:
1. общедоступный логин по правам может только законнектиться к БД и только вызвать ХП регистрации
2. ХП регистрации получает "сертификат" пользователя - можно по серьёзному, типа X-509 :), а можно тупо имя и пароль, шифрованные с учётом временно-зависимых данных, известных и серверу (ид сессии, время установки соединения и т.д.);
3. при успешной проверке пароля в ХП - сессии выдаётся роль, приписанная пользователю - у которй уже есть доступ к данымм и т.п.

Комментарии?

Dimitry SibiryakovАнатоЛойКомментарии?
Что помешает гаду типа меня назначить себе роль, не вызывая эту мега-процедуру?

Отсутствие прав на назначение себе роли у общедоступного логина.
Отсутствие прав на назначение себе роли у пользователя.
Такие права есть только у ХП регистрации.
Чтобі она отработатла "корректно" - вы должны передать ей "корректные" временно-зависимые параметры ;)

АнатоЛойDimitry Sibiryakovпропущено...

Что помешает гаду типа меня назначить себе роль, не вызывая эту мега-процедуру?

Отсутствие прав на назначение себе роли у общедоступного логина.
Отсутствие прав на назначение себе роли у пользователя роли, которую получает пользователь.
Такие права есть только у ХП регистрации.
Чтобы она отработатла "корректно" - вы должны передать ей "корректные" временно-зависимые параметры ;)

Но, вопрос натолкнул на мысль: видать не во всякой СУБД есть ХП, которые могут получить доступ к данным, на доступ к которым напрямую нет прав у самого пользователя...

Dimitry Sibiryakov, согласен.