Недостаточно прав доступа или опять забыли дать права на новые объекты

Администрирование - Защита, права, пароли

При постоянной доработке конфигураций в больших коллективах иногда возникает ситуация, когда программист поместил новые объекты в базу, а права на них дать забыл. При этом обновлять базу не позволяет бизнес. Что же делать? Есть небольшая хитрость.

Сразу скажу, что, возможно, это боян и все об этом знают 1000 лет и используют, но я не нашел на Инфостарте упоминаний о подобном решении. Так же опережу тех, кто будет говорить о регламентах и автотестировании, все это не дает 100% гарантии отсутствия ошибок, а лишь уменьшает их вероятность и шанс, что вас затронет эта ошибка, все равно есть. 

Теперь к описанию проблемы: Рассмотрим типичную ситуацию: разработчик поместил в хранилище новый объект из своей базы, а дать права нужным пользователям на этот объект забыл. В итоге мы можем получить ошибки, связанные с тем, что пользователям в рабочей базе после обновления, даже тем, для кого этот функционал и не предназначался, будут сыпаться ошибки о то, что у них не хватает прав.

Обычно такую проблему решают следующими способами:

  1. Повторным обновлением. Дали по шапке автору проблемы, уведомили бизнес и обновили. Есть проблема: на некоторых предприятиях автомобили загружаются и разгружаются раз 5-10 мин и остановка базы для обновления вне регламентного периода - это ЧП, простои, очереди, штрафы и прочие прелести. К тому же, на некоторых предприятиях установлены SLA и их нормативы не позволят вам остановить базу.
  2. Динамическое обновление. Мы можем обновить базу динамически, т.к. реструктуризации нам не требуется, меняется только роль. Но у динамического обновления есть и свои минусы: возможные проблемы с доступностью и целостностью базы, проблемы с пользовательских и серверным кешем, возможные проблемы обменов РИБ, в связи с различием версий конфигурации.
  3. Временное присвоение пользователям административных прав. Решение рабочее, но все мы понимаем, чем выстлана дорога в одном крайне неприятном направлении, где пахнет серой и довольно жарко. Скажем прямо, решение очень не однозначное. Применять его можно только для доверенных и ответственных пользователей.

Есть и другое решение. Оно довольно очевидно, но его довольно редко применяют. Или может просто мне так не повезло. Если это так, то уберу публикацию в архив и посыплю голову пеплом :)

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

Если боян, извините, пепел уже заготовлен и ждет своего часа. :)

См. также

Комментарии
1. _smile_ 06.04.17 17:46 Сейчас в теме
Нормальное решение. Взял на заметку. Спасибо.
user600603_v.soldatova; BigBoss; prettyj; TreeDogNight; myr4ik07; MoshkovEV; sorb; veretennikoff; linkov; Dmitri93; sepnotican; Mi4man; Artem-B; корум; Krio2; madonov; +16 Ответить
2. Игорь Полосков (ipoloskov) 58 06.04.17 17:51 Сейчас в теме
нам нужно только периодически ее очищать от них

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

Посему предлагаю модификацию метода:
- Создаем роли Спецроль1 и Спецроль2.
- Спецроль1 назначаем пользователям, в нее регистрируем все новые объекты.
- В момент времени "Т":
-- Очищаем Спецроль2.
-- Отключаем пользователям Спецроль1, включаем Спецроль2.
-- Отключаем регистрацию новых для Спецроль1, включаем для Спецроль2.
-- В случае проблем включаем пользователям Спецроль1, а к разработчику применяем Ипатиевский метод.
vavvv; Yasen; falsepilot; romankoav; Lena272; корум; h00k; +7 Ответить
16. BAZIL BAZIL (wbazil) 106 07.04.17 12:46 Сейчас в теме
(2) Зачем такие сложности, можно перед очисткой сначала на день два неделю, отключить спецроль у пользователей

Автору, спасибо взял на заметку.
17. Алексей Соловьев (Silenser) 428 07.04.17 15:18 Сейчас в теме
(2) Нашли косяк, стали проверять тщательнее и предметно (как детектор взаимоблокировок в MS SQL). Вероятность повторной ошибки при этом уже около нулевая. Тут главное не переборщить с бюрократией, любую даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний :)
Deslime; necropunk; Lena272; +3 Ответить
23. Дмитрий Гордеев (dinn) 08.04.17 13:17 Сейчас в теме
(2) Взял на заметку Ипатиевский метод
3. Владислав Знов (znov) 06.04.17 17:53 Сейчас в теме
Взял на заметку тоже. Спасибо.
4. Сергей Ожерельев (Поручик) 3634 06.04.17 22:13 Сейчас в теме
Во, нормально. Запомню на будущее. Сам бы не догадался.
xantif_2000; Krio2; +2 Ответить
5. Виталий Фролов (vita8383) 06.04.17 23:27 Сейчас в теме
Главное у данной роли не забывать снимать флаг "Интерактивное удаление" у добавляемых объектов.
IvanovAV; TreeDogNight; MoshkovEV; veretennikoff; linkov; Deslime; sulfur17; xantif_2000; Lena272; unknown181538; CSiER; Krio2; +12 Ответить
18. Алексей Соловьев (Silenser) 428 07.04.17 15:20 Сейчас в теме
(5) Да понятно, что это выбор из двух вариантов: плохой и очень плохой. Только вот альтернативы какие?
6. Николай Зайков (Mortiferus) 277 07.04.17 08:16 Сейчас в теме
Отлично! Сам бы не сообразил. Постоянно натыкаюсь на эту проблему.
7. Иван Иванов (Famza) 80 07.04.17 08:36 Сейчас в теме
8. Андрей Моисеев (nihfalck) 07.04.17 08:48 Сейчас в теме
решение на поверхности... ведь каждый знает про эти галочки... но вот не догадался о таком применении) спасибо за идею.
и про интерактивное удаление - мне кажется не большой это "косяк". новые объекты же - чего там удалять? невелика вероятность что серьезно порушат ссылочную целостность, имхо.
32. Maximilian Alekseevich (1cmax) 151 12.04.17 07:17 Сейчас в теме
(8) ну кто как. я сразу же смекнул.
9. Александр Васильев (user633533_encantado) 2 07.04.17 09:31 Сейчас в теме
Интересное решение. Сам обычно взял за правило: создал новые объекты - протестируй под пользователями с ограниченными правами.
Lena272; ВладимирVolodya; +2 Ответить
10. Владимир Свой (user723701) 07.04.17 09:49 Сейчас в теме
Прикольно, положу в копилочку
11. Павел Жихарев (palsergeich) 07.04.17 10:36 Сейчас в теме
А потом выгрузка данных оказывается у конкурентов.
Или при ошибке/злонамеренно будет переименован справочник и потом все бегают не могут понять, что случилось.
Лучше внеочередное обновление, чем дыра в безопасности, о которой узнают не скоро, и достанется всем.
Особенно интересно, как потом СБ доказать, что это сделано случайно, потому что лень ставить галки в новых объектах, а не был преступный сговор.
А еще лучше не допускать таких ошибок.
TreeDogNight; omut; Михаська; artfa; jig; Lena272; +6 Ответить
13. Андрей Моисеев (nihfalck) 07.04.17 11:03 Сейчас в теме
(11) Все зависит от того, что за объект новый, кто с ним работает, сколько и каких сотрудников... из двух зол выбирают меньшее. и как вариант обхода проблемы - решение хорошее. просто для примера использования: молочный завод. работа 24/7, окно для обновлений - вечер субботы (поздний вечер), 2 часа времени. добавлена обработка, но права дать забыли кому надо. что плохого в том, чтобы дать эту роль вместо демонического обновления? выгонять всех никто не даст. твои проблемы - это твои проблемы.
если такая строгая СБ, как вы пишите - то эта роль будет очень тщательно контролироваться прежде всего самим разработчиком. очищаться по мере выдачи прав в первую очередь и т.д.

ну а конечно лучше всего не ошибаться, все верно. вопрос в том что делать если все таки ошибся.
19. Алексей Соловьев (Silenser) 428 07.04.17 15:27 Сейчас в теме
(11) Как я уже писал, что это решение между плохим и очень плохим.
Между делом: работая более 10 лет на крупных предприятиях, неоднократно видел подобные выгрузки из баз конкурентов. Приоткрою вам завесу тайны, большинство из них делается под правами пользователей (не ИТ) имеющих очень высокий уровень доступа к базе, я даже один раз принимал расследование в таком инциденте, когда выяснилось, что информация была слита на уровне директората расследование закрыли и выяснять конкретное лицо не стали :) Хотя ситуации бывают разные конечно...
12. Сан Саныч (herfis) 157 07.04.17 11:01 Сейчас в теме
Хороший прием. Возможно, когда-нить пригодится. Но сейчас не нужно.
Во-первых, железный регламент вбитый на подкорку: добавил новый объект в метаданные - тут же назначаешь подсистему, определяешь отображение в интерфейсе, добавляешь роли для него, если есть планы обмена - включаешь в них. И только после этого приступаешь к разработке. Так как ролей, объединяющих несколько прав, нет (все рулится через профиля БСП) и фактически все роли используют RLS, то забыть про права сложно. В крайних случаях динамическое обновление может выручить.
TreeDogNight; swiss-garant; Lena272; +3 Ответить
14. Sergey Kotloff (kotloff) 07.04.17 11:06 Сейчас в теме
Автор, не бойся забаянить, боян на вороту не виснет :)
15. kolya_tlt kolya_tlt (kolya_tlt) 11 07.04.17 11:33 Сейчас в теме
(0) тестировать доработки перед обновлением не пробовали?
fotov; TreeDogNight; Dream_kz; artfa; unichkin; dtripleh; +6 6 Ответить
20. Алексей Соловьев (Silenser) 428 07.04.17 15:36 Сейчас в теме
(15) Если кратко, то обычно тесты покрывают не весь функционал, а только бизнес-критичный. 100% гарантии от ошибок не бывает, стандартный треугольник время - деньги - качество.
21. Денис Карпов (dtripleh) 07.04.17 15:57 Сейчас в теме
kolya_tlt прав, тестировать надо перед добавление в раб. базу, зачем усложнять систему, добавляя новые роли, при этом ещё и выполнять ненужные действия по очистке?
22. Светлана Баклан (Veterok_sv) 16 08.04.17 07:37 Сейчас в теме
Интересный подход, и я думаю это действительно меньшее зло по сравнению с динамическим обновлением. Конечно лучше не совершать ошибок, но не погрешимых не бывает, особенно программистов.
24. Александр Лопатин (lopatin) 259 08.04.17 17:05 Сейчас в теме
Так, а как это решение поможет в ситуации, когда эта проблема возникла? Вот у меня возникла проблема, как мне теперь создать эту роль не прибегаю к первому способу решения?
25. Алексей Соловьев (Silenser) 428 08.04.17 17:11 Сейчас в теме
(24)Это как с бекапами, лучше озадачиться этим заранее.
26. Олег Филиппов (comol) 3192 08.04.17 19:10 Сейчас в теме
27. Александр Аляев (alyaev.a.v) 09.04.17 21:36 Сейчас в теме
С одной стороны хорошо, но как только начнутся чистки спецроли и забывание перенести в другие роли права, проблема вернется.Универсальное решение это тесты, тесты кодера,авто тесты,тесты бизнесом.
28. Юрий (gero) 15 10.04.17 16:17 Сейчас в теме
Оригинально. Может пригодиться.
29. Джо (Johnson1987) 10 10.04.17 21:05 Сейчас в теме
Не все это знают и используют, оставляй)
30. Сергей necropunk (necropunk) 5 11.04.17 16:38 Сейчас в теме
Да, любопытное решение, за идею плюс.
31. Maximilian Alekseevich (1cmax) 151 12.04.17 07:16 Сейчас в теме
1 раз столкнулся с проблемой подобной, и сразу же принял такое же решение. потому что зачастую новые объекты типовых не особо связаны с текущими задачами по ограничению доступа и если у пользователя появятся права на новые объекты - ничего страшного, зато ошибок не будет. Результат был отменный, клиент отказался от другой обслуживающей конторы, потому что после их обновлений постоянно была проблема с правами. а после моих ни разу :)
33. Рашид Нигаметзянов (R_Wanderer) 12.04.17 07:56 Сейчас в теме
Вполне приемлемое решение. "+"
34. Art Fa (artfa) 19 12.04.17 08:40 Сейчас в теме
35. Serg (y9617730766) 12.04.17 08:49 Сейчас в теме
Как решение +, но по себе знаю что буду забывать эту хитрость: " нам нужно только периодически ее очищать от них. " В результате тестирование и еще раз тестирование.
36. Денис Каминский (ubper) 12 12.04.17 09:20 Сейчас в теме
Зачетное решение. Спасибо огромное за лайфхак. Сам то я при добавлении новых объектов первым делом иду на закладку Права.
37. Андрей Щеглов (Andrefan) 12.04.17 09:23 Сейчас в теме
Бояном даже не пахнет. Спасибо, автор!
38. Семён Павлюков (7OH) 31 12.04.17 10:12 Сейчас в теме
А, собственно, как добавление новой роли поможет там, где обновлять сейчас нельзя?
Что новую добавлять, что доработать и нормально обновить - надо остановить базу на 5 минут.
39. Сан Саныч (herfis) 157 12.04.17 10:28 Сейчас в теме
(38) Спец-роль добавляется заблаговременно. Соль в том, что права на новые объекты в нее будут насыпаться автоматически.
40. Семён Павлюков (7OH) 31 12.04.17 11:00 Сейчас в теме
(39) то есть, если есть нормальный разработчик, который всё проверил и есть у него объект, на который прав НЕ ДОЛЖНО быть - то эта роль собственно даст читать что угодно.
Тоже не вариант.
По опыту - надо тестировать хорошо.
42. Сан Саныч (herfis) 157 12.04.17 12:06 Сейчас в теме
(40) Не что угодно, а новые объекты с момента предыдущей "очистки" роли. И только тем, кому ее временно назначат с полным пониманием последствий. По-опыту - несмотря на многие "надо", случиться может всякое. Ну а кому не вариант - тому не вариант.
ЗЫ. Мне не вариант, т.к. настройка ролей на новые объекты - это отче наш и делается чуть ли не до разработки объекта. А в случае форс-мажора не имею религиозных предубеждений против демонического обновления. Благо оно уже не настолько демоническое как было и нечасто возникающие проблемы лечатся относительно безболезненно. Хотя на заре сталкивался и с крашами и с тяжело вылечиваемыми последствиями. Но если выстроенный техпроцесс подразумевает четкий регламент обновлений, исключающих демонические - то вполне себе разумная и остроумная подстраховка.
nihfalck; +1 Ответить
44. Алексей Соловьев (Silenser) 428 12.04.17 14:45 Сейчас в теме
(42) Для динамических обновлений тоже есть хинт :) http://infostart.ru/public/237871/
41. Павел Лоханев (veyron21) 118 12.04.17 11:38 Сейчас в теме
Хорошее решение. Спасибо.
Вроде все так просто и лежит на поверхности, но сам бы не додумался! Плюсую.
43. Игорь Герман (German_Tagil) 6 12.04.17 13:39 Сейчас в теме
спасибо сегодня же и применили - так совпало
45. Владимир Насыров (Spacer) 264 12.04.17 20:06 Сейчас в теме
Спасибо автору! Это отнюдь не баян, а очень даже полезная идея.
46. Дмитрий Карташев (Misamoto) 12.04.17 21:08 Сейчас в теме
Начиная с 8.3.9 роль можно добавить расширением
Silenser; +1 Ответить
50. Алексей Соловьев (Silenser) 428 18.04.17 21:12 Сейчас в теме
47. Сергей Антонов (serff) 14.04.17 01:08 Сейчас в теме
48. Анатолий Ситников (acsent) 1038 17.04.17 18:01 Сейчас в теме
Есть еще 1 способ:
У полных прав отключить автоправа на новые. тогда разраб сам столкнется с проблемой и практически наверняка добавит нужную роль
Art1387; ShantinTD; strange2007; nihfalck; +4 Ответить
49. Алексей Соловьев (Silenser) 428 18.04.17 21:11 Сейчас в теме
(48)Больше напоминает принцип "Назло бабушке уши отморожу". Тогда все сервисы и обмены нужно либо в привилегированном режиме выполнять, либо отдельную роль заводить (то есть еще одну). На мой вкус это слишком, я сторонник бритвы Окама.
51. Анатолий Ситников (acsent) 1038 20.04.17 15:03 Сейчас в теме
(49) Не понял про сервисы? какая связь?
Смысл в том, что разработчик должен сам посавить галки в полных правах руками
52. Владимир Созанский (vsozansky) 11.05.17 09:28 Сейчас в теме
Интересная метода, спасибо, буду использовать
53. cartograph cartograph (cartograph) 03.06.17 18:27 Сейчас в теме
54. Uladzimir - (nvv1970) 05.06.17 00:02 Сейчас в теме
Гораздо проще работать с правами при активной разработке решения, когда некая базовая роль имеет флаг для новых объектов и всегда устанавливается для всех пользователей как базовая. Все остальные роли расширяют права базовой. Т.е. при необходимости ограничения доступа у базовой забираем и даем дополнительной.
Вуаля. И вы никогда... НИКОГДА не имеете проблем с памятью и забывчивостью.
Оставьте свое сообщение