тут еще надо помнить, что наименование юзера (tcnalogin у вас) не может иметь пробелов и быть на кириллице ... FIRSTNAME, lastname и т.д. - пожалуйста, но не само наименование пользователя в базе

еще нужно учитывать что выполнить такую команду (процедуру) сможет только пользователь SYSDBA (или кому даны такие же права) ... давать бухy полные права на базу - такое себе...


не, можно конечно как вариант создавать отдельное кратковременное подключение как SYSDBA, выполнить добавление и отключить - тут то нет проблем



Исправлено 1 раз(а). Последнее : AndyNigmatec, 14.04.23 13:00

А динамику выполнить от sysdba можно?? не давая прав буху.





Исправлено 1 раз(а). Последнее : PaulWist, 14.04.23 13:08

PaulWist
А динамику выполнить от sysdba можно?? не давая прав буху.

- так об этом выше и написал - краткое дополнительное подключение под SYSDBA



Исправлено 1 раз(а). Последнее : AndyNigmatec, 14.04.23 13:24

AndyNigmatec

PaulWist
А динамику выполнить от sysdba можно?? не давая прав буху.

- так об этом выше и написал - краткое дополнительное подключение под SYSDBA

Не, я о другом, подключившись под юзером, выполнить процедуру от имени юзера, а динамику в этой процедуре от имени sysdba, те не подключаясь к БД от имени sysdba.

про такой вариант не могу ничего сказать, тут нужно доки почитать - не уверен что такая возможность вообще имеется.

AndyNigmatec
...
но я такие конструкции не люблю ... они не проверяются компилятором при компилировании процедуры ...

Мой скрипт как раз IBExpert не пускал, это наверное и есть некий компилятор.
Ваш пропускает, уже хорошо )

А что с кавычками, чего их так много? Но если лишние убрать - ошибка компилятора пишет.
И очень технически важный момент (извините ) - а где на клаве есть такой символ " | " ?

Обратный слэш на Eng \ |

PaulWist
А динамику выполнить от sysdba можно?? не давая прав буху.

Первое представление о ФБ говорит, что вроде бы буху в роль можно добавить право на добавление-корректирование юзеров, т.е. пользователей может быть 10, а ролей, например, 3 : админ (тут понимаем в том числе sysdba), бух, юзер.
И вот бух может последних двух редактировать.
Это такое абстрактное представление сложилось у меня, до ролей не дошел еще.

Т.е. sysdba или admin должны буха заводить, ставить ему чекбокс "редактирование пользователей" в форме, а там тот уже сам. Такая была идея, так можно?



Исправлено 1 раз(а). Последнее : DmitryKn, 14.04.23 14:05

И тогда еще вопрос - я все время путаюсь с PSQL, DSQL, когда и кто выполняется.
Вообще можно будет в процедуру IF и CASE напихать, что бы вот эти все права и роли раздавать в зависимости от параметров из фокса (или уже можно говорить из клиента) ?



Исправлено 1 раз(а). Последнее : DmitryKn, 14.04.23 14:11

символ рядом с Enter ))))

Эта команда (create user) видимо не задумывалась для выполнения "ран-тайм", соотв. не желает принимать параметры в виде именно параметров. Это мы "объехали" написав готовую команду в виде строки и динамически выполнив ее (execute statement).

Любая процедура в базе при сохранении компилируется и соотв. при этом проверяется синтаксис. Понятно, что просто некую переменную обьявленную как строка компилятор спокойно пропускает (строка она и есть строка) - он же не знает что потом в ней может быть. И вот потом при ее запуске на исполнение (execute statement) может и всплыть что угодно (мало ли как эта строка формируется).

Можно это понимать как аналогию с EXECSCRIPT() или даже макроподстановке в фоксе

теперь по кавычкам нам в команде нужно передавать пароль и прочие имена в кавычках

CREATE USER user1 PASSWORD 'pass' FIRSTNAME 'fgfgfgf' и т.д.

но в таких же одинарных кавычках у нас оформляется сама строка, соотв. для вставки этой одинарной кавычки в строку мы экранируем ее еще одной одинарной

т.е. это (пусть ваше :tcnalogin = 'user1')
'CREATE USER ' || trim(:tcnalogin) || ' PASSWORD '''
в строку запишется
CREATE USER user1 PASSWORD '



Исправлено 2 раз(а). Последнее : AndyNigmatec, 14.04.23 14:14

DmitryKn
Вообще можно будет в процедуру IF и CASE напихать, что бы вот эти все права и роли раздавать в зависимости от параметров из фокса (или уже можно говорить из клиента) ?

ну вот зачем if и прочие case ))))

сделайте вы таблицу с соответствующими вашим требованиям полями - делов то ))))

AndyNigmatec

DmitryKn
Вообще можно будет в процедуру IF и CASE напихать, что бы вот эти все права и роли раздавать в зависимости от параметров из фокса (или уже можно говорить из клиента) ?

ну вот зачем if и прочие case ))))

сделайте вы таблицу с соответствующими вашим требованиям полями - делов то ))))

такая таблица в ФБ существует (будет существовать).
Я так это себе представлял, например - админ создает буха, заводит имена, и ставит ему флажок "пользователи" (или как-то еще заполняет какое-то поле fld1). Потом это все сохраняется, и по признаку в fld1 раздаются права на создание-редактирование юзера. В той же процедуре допишется, будет CREATE OR ALTER USER , и вот там и будут всякие прочие case формировать строку lcquerytext .
Или как правильно?

Как правильно я не скажу ... сам любитель )))

Предлагаю для начала опишите как сейчас у вас это реализовано в проге, от этого оттолкнемся

есть в базе дбф таблица, в ней вся инфа по пользователям, среди прочей есть поле ial , в нем число, устанавливающее "уровень доступа".
при старте проги создается объект goApp и в нем такое же свойство. Когда юзер логинится, в goApp.ial пишется это число, при запуске формы или чего-нить там проверяется
if goApp.ial < 5 && (например)
this.enabled = .f.
endif
Подразумевается, что пользователи могут иметь одинаковые уровни.

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

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

Предварительно, я полагал задать 2-3, максимум 4 роли, и их присваивать юзерам. А какие-то отдельные вещи можно чекбоксом, например, редактирование пользователей бухам, флажок можно снять, не меняя роли, и право отнимется, как-то так.

П.С. А как у вас?



Исправлено 2 раз(а). Последнее : DmitryKn, 14.04.23 15:45

Доступ обычно разделяется на 2 уровня.

1. Первый уровень - доступ к данным, рулится привилегиями сервера (select, update, insert, delete, exec). Создаются роли, которым разрешаются/запрещаются действиями с данними

2. Второй уровень - доступ к элементам интерфейса.
Создаются роли приложения (не путать с application role сервера)

2.1. Доступ к меню-формам. Конструктор меню.
2.2. Доступ к контролам (Visible, Enabled).
Доступ к операциям (Добавить, удалить, редактировать, выполнить отчёт итд). Конструктор форм.

Доброго всем дня и легкого понедельника!

Поковырял роли и пользователей в ФБ, есть недопонимание.
Роли заводятся как-то невнятно, в IBEexpert во всяком случае, одному пользователю можно дать несколько, но зайти может только с одной из них, указанной явно.
Как-то сильно проще и понятнее завести несколько пользователей, по одному, условно на отдел, и дать им разрешения-запреты в IBExpert, но это в моем случае на маленькую компанию.
При этом идентификация пользователя будет происходить через обычную созданную руками таблицу, и все плюшки от "секретной базы" теряются.

Почитал еще про шифрование на форуме - волосы зашевелились на лысой голове.
Пока видится так - гостевое подключение с единственным правом на селект из таблицы users, потом идентификация по паролю из этой таблички, и переподключение в соответствии с указанным в табличке для этого пользователя StringConnect.
И пароли и StringConnect-ы шифрану, нашел на форуме шифровалку, ключ оставлю в теле проги. Понимаю, как это выглядит, но мне-то особо прятать нечего, так себе ценность в моей инфе. А на вопрос - чего тогда вообще шифрование затевать? - отвечу так - в том числе для общего развития.

Но ведь БД-то рассчитана на взрослые компании и в 100 + человек и информация может быть ценной и конфиденциальной, как же в таком случае с этими ролями ?

Привет!

Вот нафига с шифрованием заморачиваться, вы там что - атомные субмарины разрабатываете

Создать пару-тройку пользователей FB - этого за глаза хватит, и не заморачиваться с ролями.
Я бы вообще на данном этапе ограничился одним пользователем, с неадминскими правами, а реальных юзеров уже разруливать самому - все равно в проге у вас доступность/видимость пунктов обрабатывается.

AndyNigmatec
Привет!
Вот нафига с шифрованием заморачиваться, вы там что - атомные субмарины разрабатываете

Нет конечно, в порядке самообразования, я же писал, интересно, и идеологически - верно )

Цитата:

Создать пару-тройку пользователей FB - этого за глаза хватит, и не заморачиваться с ролями.
Я бы вообще на данном этапе ограничился одним пользователем, с неадминскими правами, а реальных юзеров уже разруливать самому - все равно в проге у вас доступность/видимость пунктов обрабатывается.

Вот в IBExpert красно-зелеными кнопками все расставил, удобно. Но в принципе, как эта проблема решается в крупной компании? Походу, там отдельное приложение создавать надо.
А 4 юзеров создать будет правильно, я им этими кнопками все и раздам, и что-то еще контролами на фоксе порегулирую.

Но вот с ролями все как-то совсем не просто, нет четкой грани между пользователем и ролью. Причем может быть несколько ролей у пользователя и несколько пользователей с одной ролью. Я досконольно не разобрал это, и сейчас в ситуации, когда члену профсоюза объясняют диалектику материализма, единство и борьбу противоположностей и прочую переписку Энельса с Каутским, напридумывали херни разной...

роль - это всего лишь "контейнер" привелегий.

Вопрос - а чего достичь хотите раздав права на чтение/запись/выполнение ХП разным пользователям FB?
Ваша прога на фоксе все равно об этих привелегиях в базе будет "не в курсе", только наткнется на невозможность каких-либо действий под определенными FB-пользователями ... т.е. в приложении вам все равно самостоятельно это разруливать.