Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.09.09;
Скачать: [xml.tar.bz2];

Вниз

Interbase, роль   Найти похожие ветки 

 
Анонимщик   (2002-07-27 18:03) [0]

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


 
Alexandr   (2002-07-29 08:03) [1]

хорошо еще что не "с какой целью"

см.
current_user (user)
current_role

ну а пароль-то нах... ой, зачем?


 
Анонимщик   (2002-08-02 20:03) [2]

В некоторой таблице в некоем поле помещаю имя пользователя. Потом делаю View
select table1.id, table1.Dolzhnost from table1, table2 where table2.idT1 = table1.id and table2.name = user
Тогда видны только те записи, что нужно. С той же целью, приблизительно, и роль. А пароль - для комплекта.


 
Alexandr   (2002-08-05 08:38) [3]

ну хорошо. В чем проблема?

насчет комплекта непонятно...



 
Анонимщик   (2002-08-05 20:11) [4]

С логином все понятно, пишем user, и сервер понимает, о ком идет речь. С паролем - ладно, на самом деле он мне не нужен. А права на редактирование таблиц предоставляется в зависимости от роли. Так вот, чтобы пункт меню, скажем, был недоступен (который дает возможность открыть таблицу для редактирования), при запуске программы следует, по-моему, сделать некий запрос и, в случае, если у данного пользователя при данной роли есть нет права редактирования, то и не давать возможности пользователю по этому пункту меню щелкнуть. Это все.


 
Анонимщик   (2002-08-09 20:05) [5]

Ребята, ответит кто-нибудь или нет, а? Как на сервере узнать роль, под которой вошел пользователь?


 
elv   (2002-08-10 13:37) [6]

Не знаю зачем тебе это надо
См. запросы к системным таблицам. Напр. RDB$USER_PRIVILEGES

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


 
Анонимщик   (2002-08-14 19:10) [7]

Ребята, ну почему вы не отвечаете на вопрос, а пытаетесь его сформулировать по-другому? На самом деле мне это нужно, чтобы триггер решал, позволять изменять запись пользователю с данной ролью, или нет. ЧТо касается запросов к системным таблицам, то из этого можно только получить информацию о том, есть ли у какого-то пользователя какая-то роль или нет. А под какой именно ролью он зашел - не знаю, каким образом узнать. Слышал, правда, что в какой-то версии Firebird"а есть глобальная переменная для пользователя - что-то типа current_role, но в какой именно, и правда ли это - не знаю. Еще слышал, что Interbase информацию о роли держит у себя где-то, и узнать ответ на мой вопрос нельзя. Пожалуйста, подтвердите или опровергните это.


 
elv   (2002-08-14 19:39) [8]

Анонимщик © (14.08.02 19:10)

Ребята, ну почему вы не отвечаете на вопрос, а пытаетесь его сформулировать по-другому?

Запомни! Пользователю надо давать то, что ему нужно, а не то, что он хочет.
В твоем случае ты "неверно" администришь. Если у пользователя есть права изменять таблицу он ее изменит. Если нет, то как ни странно нет. Не надо проверки возлагать на тригер.
Если бы ты хотел решить проблему, которую ты создал своими собственными руками, то сходил бы на www.ibase.ru почитал бы статьи.
Например такую.
Пользователи, права.
Для того, что бы получить доступ к базе данных, нужно быть пользователем, прописанным на InterBase-сервере, и иметь пароль. Но этого не достаточно, чтобы оперировать с объектами базы данных. Пользователь должен иметь права на выполнение той или иной операции.

Посмотреть, какие пользователи известны серверу можно, используя базу данных Isc4.gdb.

select USER_NAME, FIRST_NAME, MIDDLE_NAME, LAST_NAME
from USERS
order by USER_NAME;

Этот запрос даст список имен пользователей, а также их имена и фамилии. Помимо пользователей обычных можно определять роли, давать им права, а потом пользователям назначать роли.

Посмотрим, какие роли есть в базе данных.

select * from RDB$ROLES;
Поле RDB$ROLE_NAME - содержит имя роли, а поле RDB$OWNER_NAME - содержит имя пользователя, создавшего роль.

Посмотрим теперь, что можно узнать про права того или иного пользователя, по отношению к объектам базы данных. Информацию об этом можно найти в таблице RDB$USER_PRIVILEGES.

select RDB$GRANTOR, RDB$PRIVILEGE, RDB$GRANT_OPTION, RDB$RELATION_NAME
from RDB$USER_PRIVILEGES
where RDB$USER="SVETA";

Приведенный выше SQL-запрос показывает все права пользователя SVETA. Поле RDB$GRANTOR - содержит имя пользователя, предоставившего это право. RDB$PRIVILEGE - описывает привилегию (расшифровка значений приведена в документации). RDB$GRANT_OPTION определяет, может ли пользователь, получивший эту привилегию, передать ее другому пользователю. Если значение равно единице, то такая возможность есть. RDB$RELATION_NAME - наименование объекта базы данных, для которого привилегия допустима. А как узнать привилегии, назначенные ролям?

select a.RDB$USER, a.RDB$GRANTOR, a.RDB$PRIVILEGE,
a.RDB$GRANT_OPTION, a.RDB$RELATION_NAME
from RDB$USER_PRIVILEGES a, RDB$ROLES b
where a.RDB$USER = b.RDB$ROLE_NAME;

Этот запрос почти идентичен предыдущему по выдаваемым результатам, кроме поля a.RDB$USER. Оно содержит, в данном случае, наименование роли.

Изменив немного предыдущий запрос, можно узнать, права каких ролей кому предоставлены.

select a.RDB$USER, a.RDB$GRANTOR, a.RDB$PRIVILEGE,
a.RDB$GRANT_OPTION, a.RDB$RELATION_NAME
from RDB$USER_PRIVILEGES a, RDB$ROLES b
where a.RDB$RELATION_NAME = b.RDB$ROLE_NAME;



 
Анонимщик   (2002-08-16 20:43) [9]

Все верно. Только, во-первых, не хамите, а, во-вторых, пользователь может заходить и под разными ролями, и это не рукотворная проблема, точнее, мои руки здесь ни при чем. Так была поставлена задача заказчиком. Вы можете сообразить, зачем это нужно или подробнее объяснить, раз уж без этого нельзя? Поэтому я, конечно, получу те роли, под которыми пользователь может войти, но не буду знать, под какой он вошел фактически.
И не цитируйте статьи, пожалуйста, в таком объеме, если видите во мне глупца, давайте лучше ссылки - Вам же проще.
Пользовательможет выполнить запрс типа
select * from table1 where name1 = user
Результатом будут все записи, где name1 = "Анонимщик". То же самое я хочу сделать и для роли. Можно ли єто сделать? Можете даже считать, что это вопрос для удовлетворения любопытства, поэтому не нужно его заменять другим.


 
Анонимщик   (2002-08-16 22:14) [10]

Наверное, все-таки нужно объяснить. Нужно давать права на запись, чтение, удаление не только всей таблицы полностью, но и каждой записи. Если Вы, elv, объясните мне, как это сделать, вопрос будет решен. Но дополнительная проблема при этом - в том, что пользователь может быть включен в разные группы, из-за этого и проблемы.


 
elv   (2002-08-17 15:08) [11]

Анонимщик © (16.08.02 20:43)
Все верно.
Спасибо, я польщен. ;)
Только, во-первых, не хамите,
Пожалуйста процитируй мое хамство.
а, во-вторых, пользователь может заходить и под разными ролями, и это не рукотворная проблема, точнее, мои руки здесь ни при чем. Так была поставлена задача заказчиком.
Тебе задачу ставят на таком уровне? Честное слово я с таким еще не сталкивался.
Вы можете сообразить, зачем это нужно или подробнее объяснить, раз уж без этого нельзя?
Можешь не объяснять. Мне все равно решишь ты свою надуманную проблему или нет.
Поэтому я, конечно, получу те роли, под которыми пользователь может войти, но не буду знать, под какой он вошел фактически.
И не цитируйте статьи, пожалуйста, в таком объеме, если видите во мне глупца, давайте лучше ссылки - Вам же проще.

www.ibase.ru
Пользовательможет выполнить запрс типа
select * from table1 where name1 = user
Результатом будут все записи, где name1 = "Анонимщик". То же самое я хочу сделать и для роли.
Можно ли єто сделать? Можете даже считать, что это вопрос для удовлетворения любопытства, поэтому не нужно его заменять другим.

Да.


 
elv   (2002-08-17 15:30) [12]

Анонимщик © (16.08.02 22:14)
Наверное, все-таки нужно объяснить.
Хорошо хоть ч-з 20 дней решился ;))
Нужно давать права на запись, чтение, удаление не только всей таблицы полностью, но и каждой записи. Если Вы, elv, объясните мне, как это сделать, вопрос будет решен. Но дополнительная проблема при этом - в том, что пользователь может быть включен в разные группы, из-за этого и проблемы.
Существует несколько способов решения проблем. Самый лучший способ - не создавать. :) Ты безусловно можешь отмечать какой ролью добавлена запись. Мне понятен ход твоих мыслей. Если ты перечитаешь письма и все таки не поймешь как это сделать (см. Alexandr © (29.07.02 08:03)), то номер моей аськи 91724991.

P.S.Перечитай письма еще раз и не обижайся.


 
Анонимщик   (2002-08-19 14:32) [13]

Elv, спасибо, конечно. Да только в запросах работает только user, а current_user, current_role, role - нет



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.09.09;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.49 MB
Время: 0.006 c
1-27085
Чудак
2002-08-28 09:51
2002.09.09
Мастера подскажите


3-26870
Ренат
2002-08-19 14:51
2002.09.09
Часть поля в запросе


14-27205
iNew
2002-08-14 18:17
2002.09.09
Что значит туннелировать данные из одного сетевого


1-26960
partizan
2002-08-29 13:15
2002.09.09
Масив


1-26950
Zelius
2002-08-29 10:42
2002.09.09
Конфликт в пакетах BPL при загрузке Delphi6





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский