Доброго времени суток, интересуют как можно упростить ограничение доступа к базам. Сейчас у меня для каждого пользователя есть свои ini-файлы и каждому пользователю я могу прописать файл dbnam2.

Допустим одному dbnam2admins, другому dbnam2RV и т.д. Файликов этих сейчас около 15 штук, разбиты по группам, но частенько бывает что какому-то пользователю из группы надо добавить базу или отключить, можно создать еще файлик для этого пользователя, но так я приду к ситуации, когда на каждого пользователя придется заводить свой dbnam и в случае создания новой базы, которую надо добавить половине или всем, надо будет вручную всем дописывать.

можно ли сделать так чтобы видимые базы брались из нескольких файлов.
Например прописать DBNNAMECAT=dbnam2RV.mnu + dbnam2Sector.mnu ?

1. Попытайтесь спросить своих технологов, зачем им так много вариантов. Расскажите, что чем больше изменений, тем больше вероятность ошибок и больше проблем при ежегодном обновлении ИРБИСа.
2. Если разговор с технологами не пройдет в нужном ключе, покажите мой пост директору. Ему (ей) тоже неинтересно в будущем иметь проблемы ;)

я и есть технолог :)

Тогда придется находить компромисс "сам с собою" перед зеркалом ;)

Вообще идея вложенных mnu файлов витала у разработчиков, не применительно к списку баз, а для других случаев. Ну, вот приедут с Либкома из Суздаля, прочитают форум и начнут думать, как это реализовать :)
Александр Иосифович! Посмотрите на эту задачу, пожалуйста.

Вообще, на мой взгляд, регистрацию пользователей и права доступа стоит перелопатить в корне. Правильный подход был реализован в MarkSQL, там при создании (и при редактировании) можно выбрать арм к которому имеет доступ пользователь, базы данных и большое окошко с правами - что позволяло сделать какую угодно учетную запись за 30 секунд

Может быть имеет смысл что-то подобное реализовать в администраторе?

кстати, а почему бы вообще не хранить все настройки ирбиса и пользователей в частности, в служебной базе? к чему эти десятки ини-файлов?

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

какие в топку соображения безопасности, логины и пароли в текстовом виде лежат в datai

auto_02 написал(а):
-------------------------------------------------------
> какие в топку соображения безопасности, логины и
> пароли в текстовом виде лежат в datai
Во-первых, к папке DATAI (также как и ко всем данным на сервере) не должно быть файлового доступа ни у кого, кроме АДМИНИСТРАТОРА.
Во-вторых, данные о логинах и паролях можно ШИФРОВАТЬ (есть соответствующая опция).

> В БД не должно быть таких сведений, исходя для начала из соображений безопасности.

а sql, oracle и прочие где, по-вашему, хранят схему, настройки и пользователей?

> данные о логинах и паролях можно ШИФРОВАТЬ

ага. обратимым шифрованием. xD.

auto_02, ну зачем вы так сразу. тут заповедник же. :) прочитайте последние несколько сообщений из этой ветки и вам многое станет ясно. [irbis.gpntb.ru]

>Во-первых, к папке DATAI (также как и ко всем данным на сервере) не должно быть файлового доступа ни у кого, кроме АДМИНИСТРАТОРА.

А кто мешает в таком случае сделать, чтобы к служебной базе не было доступа никому кроме АДМИНИСТРАТОРА (что я вижу само собой разумеющимся)? я уж не говорю что доступ можно к базе сделать исключительно с АРМ Администратор.

И вообще, как можно придумать, чтоб на всех пользователей по дефолту !ОДИН! настроечный файл и один список баз? я уже не говорю про возможность ограничить отдельным пользователям некоторые виды действий - костыль на костыле и костылем погоняет.

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

АрПи

Цитата:

а sql, oracle и прочие где, по-вашему, хранят схему, настройки и пользователей?

Там совершенно другая структура БД. Тем более пароль хранится в зашифрованном виде, даже администратор (root) не может его посмотреть. В ИРБИСе все данные хранятся в явном виде.
auto_02

Цитата:

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

Не нужно придумывать велосипед. Может, просто следует разобраться в работе ИРБИС?



Редактировано 1 раз. Последний раз 27.11.2014 14:10 пользователем woodyfon.

Когда программа не предоставляет никаких удобоваримых инструментов управления, приходится изобретать велосипеды. А уж в работе наразбирался, спасибо. На любой маломальское действие лезть искать необходимый файл и править ручками.

Было бы очень интересно узнать, что это за ОГРОМНОЕ число файлов, которое Вам приходится корректировать. Это свидетельствует об очень глубокой и продвинутой работе администратора. Поделитесь опытом. Это тем более интересно, что большинство пользователей ИРБИС работают вообще без администратора.

woodyfon, неверно, там пароли не хранятся вообще. только хэши от них.

"Там совершенно другая структура БД." и что это принципиально меняет в вопросе возможности хранения настроек бд в самой бд?

>Было бы очень интересно узнать, что это за ОГРОМНОЕ число файлов, ?которое Вам приходится корректировать. Это свидетельствует об очень глубокой и продвинутой работе администратора. Поделитесь опытом. Это тем более интересно, что большинство пользователей ИРБИС работают вообще без администратора.

Из последнего, на вскидку, создание новых словарей, редактирование форматов вывода КК, прикручивание изображений в КК по http, а также ПОСТОЯННАЯ возня с правами доступа и кучей файлов пользователей соответственно. Многим может и не надо, а у нас 27 филиалов по городу, сами прикидывайте объем работы.

auto_02 написал(а):
-------------------------------------------------------
> >...а также
> ПОСТОЯННАЯ возня с правами доступа и кучей файлов
> пользователей соответственно.
А вот здесь, пожалуйста, поподробнее...



ногим может и не
> надо, а у нас 27 филиалов по городу, сами
> прикидывайте объем работы.

>А вот здесь, пожалуйста, поподробнее..

Первый пост в теме

auto_02, зря стараетесь, как мне кажется. только на хамство нарвётесь и всё.

Надежда на то, что надежда умирает последней, умирает последней...

Артур Юрьевич!
> auto_02, зря стараетесь, как мне кажется. только на хамство нарвётесь и всё.

Не нужно стравливать на непонятной логике.

Требуется банально уточнить задачу.
По собственному опыту скажу, что больше половины задач по автоматизации решается изданием приказа по учреждению с требованием соблюдения правил (и при нарушении прописывается наказание). И этот вариант дешевле и эффективнее, чем изобретение любого программного велосипеда, который через 10 лет придется переписывать.
И даже на 120 сотрудников и 26 филиалов в сети ИРБИС, что есть у меня в организации, достаточно сделать 2 базы (одну библиографическую, одну читателей), а вариаций dbname2 - 26 штук (по-филиально). Все остальное разделяется нормативной документацией.
Поскольку, если есть задача упахаться, то ее можно найти абсолютно в любой сфере.

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

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

Тут немножко другая ситуация. Базы 2 мы сделать физически не можем, так как они сугубо тематические и разделены по типу матирала, то рабочих баз получается порядка 10-15.

Административный ресурс это очень хорошо, но в данном случае

а) Горбатого могила исправит.
б) Очень много казусов из-за невнимательности работников - не в ту базу внесла и т.д.

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

Пункт В) собственно и подводит меня к вопросу КАК сделать то, что описано в первом посте. В принципе эта тема могла закончится на втором посте, который должен был содержать фразу "на данный момент технически невозможно".

auto_02 написал(а):
-------------------------------------------------------
> Тут немножко другая ситуация. Базы 2 мы сделать
> физически не можем, так как они сугубо
> тематические и разделены по типу матирала, то
> рабочих баз получается порядка 10-15.
Абсолютно ошибочное решение. Вы неверно трактуете понятие БД в ИРБИСе



> Административный ресурс это очень хорошо, но в
> данном случае
>
> а) Горбатого могила исправит.
> б) Очень много казусов из-за невнимательности
> работников - не в ту базу внесла и т.д.
>
> в) Как системщик, я четко уверен что пунктов
> А и Б можно легко избежать (и во многих местах
> избегаем), если дать пользователю минимально
> необходимый для работы набор разрешений. Все
> остальное должно быть закрыто.
>
> Пункт В) собственно и подводит меня к вопросу КАК
> сделать то, что описано в первом посте. В принципе
> эта тема могла закончится на втором посте, который
> должен был содержать фразу "на данный момент
> технически невозможно".

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

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

RuSS, мне кажется, это методика решения проблем такая - "административная". вот смотрите отвлеченная тема - спецсимволы в webirbis ( [irbis.gpntb.ru] )
кратко: "веб-ирбис при поиске фильтрует спецсимволы типа @$& и т.д."
решение: "эти символы следует считать зарезервированными в WEB ИРБИС."
разве это решение?

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



Редактировано 1 раз. Последний раз 01.12.2014 12:14 пользователем АрПи.

Жаль, что мой посыл был неправильно понят.
Я писал, в общем, что нужно поговорить с технологом, который желает навести порядок в технологиях (т.е. технолог - сотрудник с библиотечным образованием, знающий хорошо ПО и технику), и который спроектирует процессы так, чтобы не было 5-ти разных библиографических баз. Это позволит упростить работу всем.
Именно это и называется административным решением проблемы через настройку бизнес-процессов (технологических процессов), чтобы через доверие отдельных групп сотрудников придти к построению единого информационного поля. А не мучиться программировать сложную структуру. Ну да ладно.

В пятом посте этой темы я все описал, что было. Остается ждать решения разработчиков.

Артур Юрьевич! Ну а про пост с символами - ситуация там непонятная, поскольку никто и не знал, что есть символы, которые удаляются из запроса при использовании параметра S21P01 = 0. Никаких там административных решений и не предлагалось. Это все на совести разработчиков, которые зачем-то разбирают запрос в Web-ИРБИС.

Александр Сергеевич,
т.е. я неправильно понял, что озвученная позиция Кирилла Евгеньевича и есть официальная позиция разработчиков?

P.S> может отделить эти сообщения в отдельную тему, а то кажется, мы ушли в оффтопик немного.



Редактировано 1 раз. Последний раз 01.12.2014 19:39 пользователем АрПи.

Александр Сергеевич! Может Вы в том посте с символами дадите нам простым библиотекарям какой-то совет, что делать то? Мы там написали вдвоем, а что делать неясно.