Нужна свежая идея. Пароль на дату запрета редактирования. #203160

Сложность, собственно, вот в чем: у меня 10 баз, которые обновляются единным МDшником, из них 4 базы распределенные. МDшник должен быть абсолютно идентичным для всех, это мое принципиальное решение. Каждый главбух должен получить возможность придумывть и устанавливать самостоятельно пароль на дату запрета редактирования (ДЗР) в режиме предприятия. Причем в одних перефирийных базах никто не должен имет права редактировать ДЗР, в других главбух имеет такие права. НЕ ЗНАЮ как именно это реализовать. Свои мысли пока не буду говорить, что бы не сбивать смысли других форумчан. Заранее всем спасибо.

Процедура ПриЗаписиКонстанты(ИмяКонстанты,Значение)

а нафига пароль-то? Просто правами пользователей все это дело урегулировать религия не позволяет?

права настроить

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

Слышал про НЕВИДИМУЮ КОНСТАНТУ. Что это?

см Права Пользователя, запрещаешь просмотр и корректировку всем, кроме гл.буха

В конфигураторе убираешь у всех, кроме ГБ, права на чтение даже. ГБ оставляешь. Если хочешь, можно и себе, родимому...Все.

"В Коране написано, что есть системщики в перефирийных мечетях, которе права могут подправить. " - мдя...(С)

если в переферийных мечетях системщики могут подправить права, то и пароль который та наверное пропишешь внутри процедуры вытащат тоже

следующей темой будет "нужен пароль на пароль на дату запрета редактирования"

В принципе, у меня есть переменная глПользователь. Если в спр. Пользователи создать невидимый реквизит "ПризнакЧтоЭтотПользовательШейх" для ГБ...

Понимаю ваш здоровый юмор. - Пароль не в процедуре должен быть. Например через метод ЗначениеВСтроку (или как там) сохранять :)

"пароль" на право менять константу писать в полное имя пользователя (табло закрыть) ...

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

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

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

решительно не понимаю выражения "(табло закрыть)". Можешь пояснить?

у нас серьезная служба безопасности. УЛетит база, системщик шахидом станет :(

чтобы нельзя было ПолноеИмяПользователя узнатьимхо, плохой вариант, да и нету варианта вообще, имхо

ну, понимаешь, системщикам просто необходимо "закрыть табло", чтобы много себе не позволяли

согласен на 123% :). Враги не админы - админы не враги. Враг - безнаказанность и безответственность. И кривые ручки, впрочем со всеми бывет, кроме пожалуй Дурочки1С и Майка

+19нету варианта - потому что

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

Ладно, Аллах с ним, с ними - с системщиками. Нужно, что бы ГБ сам вводил в предприятии пароль, и менял, когда захочет. И никто не знал. Без "прав" здесь не обойтись, конечно.

ЯЯЯ, тьфу... zzzz - деяния разного масштаба сравниваешь

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

В процедуре ПриЗаписиКонстанты сделай вызов обработки.На форму обработки добавь строковый реквизит с флагом "для ввода пароля".При открытии формы обработки передавай ей параметром случайное число.Введенный пароль должен быть фразой с добавлением функции от случайного числа и номера дня недели.Одновременно можно проверять КодИБ и имяПользователя для вариации фраз пароля для разных баз/пользователей.Поэтому сторонний пользователь даже завладев паролем, не сможет его использовать- не совпадет имя пользователя и неизвестная ему переменная часть пароля.Для введенной в обработке строки пароля вычисляем два контрольных числа: для постоянной и переменной части пароля, сцепляем их операцией контатекации и возращаем в процедуру ПриЗаписиКонстанты, а затем сравниваем ее с правильным хэшем, который вычисляем в процедуре. Из текста процедуры нельзя видеть пароли, поскольку вместо них приведены разные хэши для разных пользователей и их постоянной части паролей, а вычисление производиться только для переменной части пароля.Далее разрешаем изменить константу или запрещаем.

Не совсем понятно как админы поменяют права, если в периферийной базе будет только один пользователь с административными правами ? И пароль только у автора темы.Если же админы пользуются патчами отрубающие авторизацию то на мой взгляд проблему вообще не решить. Установят дату запрета внешней обработкой и все.

ПриЗаписиКонстантыработает только при интерактивном изменении константы. Против обработки бессилен

Никакие права и пароли не заменят простой внешний ЕртКонстанта.ДатаЗапретаРедактирования = НужнаяДата;

ЗВУЧИТ КРАСИВО. Сейчас буду думать как это воплотит в жизнь.

Доктор, спасибо. Но такой вариант сложно реализовать и слишком просто можно обойти. Истина где-то посередине.

ты не ответил на

2 И чем не устраивает ?

пардон, отвечаю на :Есть ГБ которые имеют это право, а есть которые не имеют этого права. Права замечательная вещь, еже ли бы не галочка "Отключить контроль прав"

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

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

В написано все что нужно, и ничего лишнего. По спартански мудрый ответ.

это ты малышам рассказывай :) Давно обрубил этот вариант.

32.Помимо константы пароль ведь можно запрашивать из процедуры глПроверкаРазрешенияРедактирования в подозрительных случаях.Например, когда дата документа не совпадает с системной датой или есть проведенные документы с более поздней датой.Таким путем я запретил правку задним числом расходных накладных неуполномоченными лицами.Мм не помогали манипуляции с системной датой, не помогла бы и программная запись константы, и даже подмена users.usr для захвата чужых прав, и даже клавиатурный шпион- пароль-то динамический. Да и сам мд зашифрован.

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

Для случаев программного изменения документов есть еще глобальная ловушка на запись в БД.

интересно, расскажи если не сложно по-подробнее.. Для других целей уж точно понадобится.

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

Убрать изменения программным способом и открыть интерактивный способ. Смотреть по монитору пользователей кто менял и откусывать руки-ноги по самую шею ...

Оглашаю решение:2) Каждому по внешей обработке с личным паролем на испоьзование внешнего отчета (по ИНН организации ПрефиксуИБ буду проверять возможность изменения в конкретной базе)3) И научу пароль менять через конфигуратор.4) Осталось только выдержки из Корана повставлять на форме диалога обработки, или карикатуры :)

Саша, не кипятись. Здесь все люди взрослые. Я ничего супротив системщиков не имею, и очень их уважаю. Но у них непосредственный начальник далеко, а свои "шишки" рядом, потому и соблазн может возникнуть Нормальная ситуация. Отвечаю на твой вопрос - в обработке "Общая настройка" в форме диалога сделал невидимым поле "ДатаЗапретаРедактирования". Вот и все.

:) да я и не кипячусь. Просто без контроля прав - все ухищрения лишь видимость защиты.

Ты как всегда прав :)

Да уж...(с)...PS. А для чего пароль ? непонятно...