Пользователь уже аутентифицирован в хранилище 1с как отключить
В общем, есть такая проблема.
Многие - и программисты(у нас их много) и иногда юзеры любят залезть в рабочую базу в конфигуратор. При этом, не зная пароль от Хранилища периодически на вопрос "Отключиться от хранилища конфигурации?" вместо того, чтобы нажать "нет" жмут "Да!", чем постоянно вызывают у меня лютый баттхерт и гору строительных материалов.
Как с этим бороться? В логах видно только того, кто заходил в конфигуратор, но никто не признается, кто отключал.
Я так и не могу понять, в чем у вас проблема? Не можете организоваться?
А, точно - вход в хранилище при открытии конфигурации происходит, а не конфигуратора.
Значит, юзеры отпадают. Осталось разделаться с программерами руками. и с начальником заодно. Наверняка он периодически отрубает.
а зачем вообще рабочую базу подключать к хранилищу? не проще ли периодически делать обновления для рабочей, а разработку вести в отдельных базах? (по одной на каждого программиста). Или как у вас? что-то не понятно
(14) нуууу. хранилище - вещь при групповой разработке.
(0) Ведите разработку в копии, а объединение с хранилищем = назначить "главного по тарелочкам".
(15)+100500
а нечего подключать рабочую базу к хранилищу.
выпустили обновление, накатили - и все.
список пользователей редактируется отлично и в режиме предприятие, во всех типовых давно реализовано
нет слов одни эмоций, юзеры доступ к базе, у нас программисты не имеют полноценный доступ, не что юзеры. введите у себя групповые политики.
(0)Убери у пользователей полный доступ.
Для редактирования пользователей - доступ в режиме предприятия.
(0) пусть каждый разработчик работает в своей базе. Тогда траблы из сабжа не будет.
Сделать в недоступном месте центральную базу, а рабочая пусть будет распределенной.
И делайте с этой ЦБ что захотите.
да просто убрать у юзеров право открывать конфигуратор и всего делов то
к чему эти многоступенчатые архитектурные изыски
(33) так есть персонифицированная история изменений рабочей базы и можно быстро откатиться на любой релиз (с нюансами правда)
(35) если бы были бранчи, то вполне.
А так — большая вероятность, что в рабочую базу влетят недопереписанные неоттестированные куски
(35) если команда состоит из одного тебя, то можно. А если - из еще хоть кого-нибудь, то тогда вы либо друг другу работу останавливаться будете, либо в рабочую базу нестабильный и не протестированный код сливать
(38) как в базу влетят недопереписанные куски если их в хранилище еще не положили?
а что такое бранчи?
(40) как это не положили? Еще как положили!
Бранчи — это ветки. Допустим, тебе надо внести какие-то изменения, которые затрагивают несколько объектов. Ты создаешь бранч — виртуальную копию конфы и вносишь изменения в ней. Другие разработчики этих изменений не видят, пока ты не объединишь бранч с общей ветвью.
(44) при этом с бранчем могут работать несколько человек. При этом они будут заливать свои изменения не в общую сконфуженно, а только в свою ветку.
(44) ну правильно, если мне надо изменить несколько объектов, то я захватываю эти несколько объектов и работаю с ними, и делаю с ними что хочу у себя, на своей отдельной базе (подключенной к общему хранилищу).
Естественно, с этими объектами никто работать не сможет, но только с этими объектами.
(44) >>Другие разработчики этих изменений не видят, пока ты не объединишь бранч с общей ветвью.
ну дык этож классический пример работы с хранилищем конфигурации. ты захватил объект, работаешь с ним, сохраняешь, изменяешь.
пока в хранилище не положил, никто его не видит.
зачем для этого бранч?
+(44) особо внимательные пионэры могут сказать: "ХА! Так а какая религия мешает скопировать хранилище?"
скопировать-то ни чего не мешает, только вот работать с этим будет трудно по дум причинам:
1. механизма слияния веток нет
2. авторизация не наследуется, что порождает лютейший баттхёрт при администрировании толпы хранилищей
3. испробовано много раз - соотношения профита и гемора не позволяет называть это "механизмом ветвления хранилища конфигурации 1С"
В результате два юнита не могут работать, пока тестеры не отчитаются о том, что и так, и эдак будет изменено потом
+(50) теоретики могут идти лесом с песнями - пример абсолютно живой и рабочий, имевший место три месяца назад
(50) а с бранчами вам типа в вашем бардаке легче было бы?
Петя с Васей захватили один и тот же объект и работают с ним, изменяют одну и ту же процедуру.
Наступило время объединаться. И чо? Кто главнее?
+(50) забыл пункт 6 - тестеры ни куя не делают по объекту А, поскольку не могут взять в толк, зачем им тестировать не законченную работу (и их легко понять)
(52) ты ни фига не понял. С бранчами Петя с васей работают в одной ветке и захватывают так же по очереди:
1. Петя с Васей не ждут тестеров и коммитят, как только они закончили работу
2. Тестеры не делают бестолковой работы
3. В конфигурацию рабочей базе ни как не могут попасть даже временно недоделки
В третьей части я показал пример обращения ко всем возможным методам, и как работать с длительными операциями.
В четвертой части показал, как работать с порциями.
для обмена данными между информационными системами;
для обмена данными с сайтами и порталами;
Клиент формирует запрос к веб-серверу.
Дальше запрос проходит какие-то проверки – проверяются заголовки, параметры, тело запроса (если сервис использует тело запроса).
Если все проверки пройдены, то выполняется некий метод в вашей конфигурации и формируется ответ с кодом состояния:
обычно, если все нормально отработало, код состояния равен 200;
если что-то пошло не так, код состояния может отличаться;
есть методики, когда используется JSON RPC – в этом случае код состояния всегда равен 200, а в теле запроса в определенной структуре JSON содержится ответ, где в параметре error пишется, какие были ошибки.
Есть ли какая-то универсальная микстура или принцип, как сделать определенные шаги для обеспечения безопасности всех сервисов, которые вы создаете? Такой микстуры, к сожалению, нет. Но есть какие-то практики, которые люди применяют в своей работе.
Настройте регулярное создание бэкапов
Простая проверка администратора на профпригодность – это поручение «Восстанови на тестовой базе вчерашний бэкап». Если администратор сможет восстановить бэкап только месячной давности, нет причин с ним дальше работать. За месяц многое может поменяться, поэтому такие вещи недопустимы, и не дай Бог с вами это произойдет.
Для чего нужен сервис?
Кто конечный потребитель?
Будет ли сервис выставлен наружу?
Эти три простых вопроса позволяют понять, какие вещи необходимо будет произвести для обеспечения безопасности.
GET для безопасных действий, POST для небезопасных
Дальше нужно определиться с тем, по каким методам будет работать ваш сервис – будет ли он использовать только GET или POST, или он будет использовать смешанные методы.
GET вызывает так называемые безопасные действия – он получает параметры и отдает некие данные из информационной базы.
POST предназначен для более опасных действий – если вы хотите передавать логин-пароль, то GET для этих случаев не подойдет, лучше передавать в теле POST.
Чтобы определиться, какой метод вам больше подходит, есть картинка, которая очень наглядно помогает выбрать тот или иной метод.
Повторюсь, что основные минусы GET по сравнению с POST – это то, что запрос можно кешировать, запросы могут оставаться в истории браузера, параметры передаются в URL, и GET не предназначен для передачи больших объемов данных.
Это – наглядный пример MITM-атаки.
Let’s Encrypt – лучше, чем самоподписанный сертификат, но есть минусы
Часто встречается, что приходишь в какую-то крупную организацию, и там используют самоподписанные сертификаты. Если сервисы используются для внутренних целей, этого достаточно. Но если вы собираетесь выставить сервис наружу для обновления какого-то мобильного приложения, такой самоподписанный сертификат не подойдет. Лучше использовать бесплатный сервис Let’s Encrypt.
Но у сервиса Let’s Encrypt есть минусы по сравнению с платными сервисами:
Нет гарантии, что с Let’s Encrypt не случится то же самое, что случилось со Startcom и Wosign. 5 лет назад был случай, что крупные производители браузеров перестали им доверять – эти сертификаты потеряли доверие.
Еще нет гарантии сертификата. Например, если клиент зайдет на сайт, который подтвержден сертификатом платного центра, и потеряет деньги в результате фишинга, то эти платные центры обязуются выплатить некую сумму (от 10 тысяч долларов до 1.5 миллионов долларов).
И основной минус – у Let’s Encrypt сертификаты выдаются на 3 месяца. С другой стороны, есть готовые скрипты, готовые боты, которые продлевают сертификат. Для Apache – это certbot, а для IIS – это win-acme.
Разделите сервисы
Соответственно, если вашу фирму начнут проверять на прочность, вздрогнет вся система, и работать будет невозможно.
Поэтому я не зря изобразил на слайде подводную лодку: если в ней случается пробоина, закупоривается один отсек, а остальная часть подводной лодки продолжает функционировать. Я тоже рекомендую разносить внутренние сервисы на одну машину, а сервисы, которые должны общаться с внешним миром на другую, возможно, даже на несколько машин.
Опубликуйте сервис и настройте на него права
Если вы организовываете внутреннюю сеть, достаточно внутри сети поставить веб-сервер – это может быть Apache, IIS, это может быть 1С:Публикатор или 1С:Линк (это тоже Apache, просто его версия от фирмы 1С с красивым интерфейсом).
К паролям нужно относиться очень бережно – про это я чуть дальше расскажу. Желательно, чтобы у сотрудников были хорошие пароли.
Используйте VPN
Если вам нужно организовать удаленный офис либо объединить в единую сеть магазины или сеть точек общественного питания, используйте для администрирования VPN – этого достаточно.
Организуйте промежуточное звено
Есть варианты с промежуточным сервисом:
Один из таких вариантов был показан на онлайн-митапе «Web-клиенты для 1С». Есть некий промежуточный сервис, написанный на каком-то стороннем языке, этот сервис смотрит наружу, получает запросы от клиентов, организует для этих запросов некие квесты – накладывается фильтрация, проверяются токены, организуется ограничение частоты вызова определенных методов или двухфакторная аутентификация. Только тогда, когда все эти квесты пройдены, запрос идет во внутреннюю сеть. Вариант неплохой, рабочий, многие его используют.
Есть еще вариант с промежуточной базой, которая получает запросы, отслеживает, что в этом запросе все хорошо, и тогда уже передает его во внутреннюю систему.
Получается, что эти промежуточные звенья принимают первый удар на себя, а если с ними что-нибудь случится, ваша информационная база будет в безопасности.
То же самое можно делать и другими средствами:
можно установить файрвол, который ограничивает доступ, делает фильтрацию IP, закрывает порты;
за файрволом можно поставить реверсный прокси, на котором тоже настроены какие-то фильтры – реверсный прокси-сервер может выполнять функцию балансировки – он разграничивает нагрузку между сервисами и дополнительно уменьшает трафик за счет кеширования.
Это тоже рабочий вариант.
Пройдите аудит ИБ
Даже если у вас все отлично настроено, все отлично работает, можно еще произвести аудит информационной безопасности. Это актуально, поскольку система развивается, в ней появляются новые дыры, и их надо своевременно отслеживать.
Какие-то фирмы проводят аудит раз в полгода, кто-то – раз в год. Какие-то фирмы начинают проводить аудит только тогда, когда с ними что-то случается.
Но проводить аудит – дело полезное. Вы получите обратную связь, получите отчет о том, что было проделано, узнаете, какие у вас есть дыры в безопасности. Если у вас нет возможности проводить аудит своими силами, есть сторонние организации, которые этим занимаются.
Проводите постоянный мониторинг
Нужно производить постоянный мониторинг системы. Даже если у вас все работает, следовать правилу «Работает – не трожь» не совсем правильно. Система работает до тех пор, пока вы ее обслуживаете. Соответственно, можно настроить какие-то сборы метрик, можно проверять логирование. В 2019 году на Инфостарте был очень хороший доклад «Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей». Докладчик рассказывал о том, как у них некая нейронная сеть отлавливает некие изменения в системе и на основании этих изменений делает какие-то действия, сообщает о каких-то ошибках.
Если пойти этим же путем, анализировать все эти метрики, логи, то в принципе тоже можно сделать такого автоадминистратора, который все эти вещи будет сам отлавливать. Я думаю, что даже в каких-то крупных ИТ-гигантах такие вещи уже сделаны и успешно работают.
Храните логи в недоступном от злоумышленников месте
О чем еще важно помнить? Допустим, у вас есть логи, которые вы храните не очень защищенно. Логи тоже могут иметь некую конфиденциальную информацию.
Например, в логах хранится заголовок запросов с базовой авторизацией. Соответственно, если злоумышленник получит эти логи, он их без труда декодирует и получит доступ к вашей базе под этой учетной записью.
Относитесь к паролям бережно
Еще раз напомню, что к паролям нужно относиться бережно. В практике моей компании был один случай: до 2018 года у нас администратора не было, состояние системы было подзаброшено, и мы наняли очень хорошего администратора, чтобы он все настроил. А потом директор решил проверить, действительно ли теперь все так хорошо, и обратился к моему коллеге, попросил его за хорошее вознаграждение взломать систему. У меня коллега далеко не хакер, он просто 1С-программист, который знал, что в компании есть некая база, которая опубликована наружу. Он открыл эту базу через браузер, быстро подобрал пароль к учетке пользователя-администратора с правом открытия внешних обработок, вошел в базу, открыл в ней обработку и сделал принтскрины, доказывающие, что у него полный доступ ко всем данным. Пароль был 123.
Как перечеркнуть все усилия по обеспечению безопасности
В феврале этого года я выложил статью «Выполнятор – как я породил монстра и лишился сна!». Это случай из 2017-го года. Я тоже человек грешный, я реализовал некое очень страшное решение через метод «Выполнить()».
Самое интересное, что такие статьи выходят на Инфостарте регулярно, я примерно раз в месяц вижу новую статью с таким решением.
Если я вижу такую статью, я пытаюсь пообщаться с автором и объяснить, почему так делать не стоит – об этом я расскажу дальше.
Все эти «Выполняторы» работают по одному принципу с небольшими отличиями:
кто-то передает текст команды,
кто-то передает текст команды и параметры,
кто-то передает текст запроса и параметры;
кто-то передает просто текст запроса.
Дальше это все попадает в некий метод «Выполнить()», где все это выполняется. Это некий троянский конь, через который с вашей системой можно что угодно сделать, вплоть до очистки всех данных.
Есть статья на ИТС «Ограничения на использование Выполнить и Вычислить на сервере». Если вы решили сделать универсальное решение, то ознакомьтесь с этой статьей, все вопросы уйдут.
Когда я общался с авторами, я интересовался, почему они сделали такое решение:
Некоторые, как и я, хотели выйти из конфигуратора – статья про «Выполнятор» как раз показывает, что так делать неправильно.
Кто-то говорил, что ему не нравится писать код в двух местах – в конфигурации-источнике и конфигурации-приемнике.
Основные минусы «Выполняторов»:
Практически невозможно отловить неоптимальный код. В базе-источнике будет видно только то, что выполняются некие методы. Вы не отловите, какой там код в какой момент пришел.
Плюс вы постоянно пересылаете весь код и параметры, что тоже нехорошо. Это то же самое, как если вы придете в библиотеку, положите перед библиотекарем три тома «Войны и мир» и спросите: «Что написано во втором томе на 300-й странице в пятом параграфе?» Получается, что вам, чтобы спросить какую-то вещь, нужно постоянно носить эти книжки. Это тоже не совсем хорошо.
И возможность потерять все свои данные – я про это уже говорил.
Стояла задача создать мобильное приложение, которое будет обмениваться с ERP. Мы планировали его устанавливать на планшеты пользователей и настраивать силами сотрудников ИТ-отдела.
Для этой цели у меня в ERP был создан план обмена, на узле которого хранится не логин/пароль, а некий сформированный хэш. И с мобильного приложения тоже гоняется не логин/пароль, а некий хэш. Эти хэши сравниваются и обмен производится только при их совпадении.
алгоритмы и методы – это отдельные справочники;
различные методы логирования;
запуск фоновых заданий для алгоритмов.
можно указать конкретный метод, который будет обработан;
на закладке «Параметры» рассчитываются параметры, которые будут использованы на закладке «Вычисления»;
указывается алгоритм, который формирует ответ от базы;
можно задать заголовки ответа и т.д.
Учитывая, что система универсальных методов уже была, на разработку полноценного рабочего окружения для мобильного приложения ушло 3 недели.
Заключение
Плюс заказчик получает готовую функциональность, реализацию которой не нужно оплачивать – все можно сделать силами одного 1С-ника.
Вопросы
Какие вы можете порекомендовать средства для хранения паролей к внешним сервисам, с которыми интегрируется 1С?
1С рекомендует использовать для этого безопасное хранилище. Но я обычно делаю свое хранилище значений. И в нем уже в определенной структуре храню такие вещи.
В кейсе про мобильное приложение, о котором я рассказывал, я не гоняю пароль в явном виде, я просто гоняю некий хэш.
Вы говорите про то, как хранятся пароли внутри 1С, а снаружи? Если нужно обмениваться паролем между командой разработки и инфраструктурщиками? Используете ли вы какие-то сервисы для этого?
Можно хранить секреты в файле на сервере с ограниченным доступом, либо в специальном сервисе. В базу добавляем ПараметрСеанса, в который будем считывать секреты, и запрещаем доступ к этому параметру сеанса.
Вызов внешнего сервиса делаем таким образом
Если базу выгрузить, то секреты никуда не утекут.
Какие VPN-сервисы рекомендуете для внутренних сервисов? Или лучше написать свой?
OpenVPN – самый распространенный, используем его.
Как правильно выставлять сервис наружу? Лучше всегда закрывать веб-сервисы, которые выдаются наружу? Или в каких-то случаях не закрывать?
Если для вас это будет очень больно, лучше этого не делать. Если вы обслуживаетесь у каких-то аутсорсеров, а вас начнут проверять на прочность, то вам нужно будет сначала дозвониться, дождаться, когда специалист с вами через час свяжется, и только потом вам, может быть, помогут. В таких условиях лучше ничего не выставлять наружу.
Если вам нужно обмениваться с сайтом или сторонним сервисом, есть хорошие средства, я про них в докладе уже упоминал.
А есть какие-то готовые инструменты для защиты базы от внешнего доступа? Какими сервисами можно воспользоваться 1С-нику?
Очень многие используют nginx, это хорошее программное обеспечение, его можно использовать как реверсное прокси для балансировки и фильтрации запросов.
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Безопасность в 1С". Больше статей можно прочитать здесь.
При работе с хранилищем конфигурации время от времени могут возникать ошибки, предупреждения, которые не всегда являются критичными, и легко устраняются. Но зачастую разработчики, особенно новые, с ошибками не знакомы, или путаются в них, поэтому решено было собрать все ошибки и способы их решения в одном месте.
Речь пойдет о файловом варианте работы с хранилищем.
1. Ошибка аутентификации в хранилище конфигурации
Самая понятная из возможных ошибок. Данная ошибка возникает при вводе неверного логина и пароля.
Изменить логин и пароль может пользователь с административными правами на вкладке "Пользователи" окна "Администрирование хранилища конфигурации"
2. Пользователь существующей связи отличается от текущего
Тут важно понимать принцип работы хранилища конфигурации. Хранилище используются для коллективной разработки, т.е. у каждого разработчика есть своя база для разработки, есть свой пользователь хранилища, и все под своими логинами подключаются в свои базы. На практике бывает, что существуют общие базы, например на сервере для тестирования, и если она подключается к хранилищу, для нее необходимо заводить также отдельный логин и заходить в нее под ним (для удобства, в качество логина общей серверной базы можно использовать имя самой базы). Девиз хранилища: на каждую базу свой логин в хранилище.
Данная ошибка возникает, когда текущая база уже подключена к хранилищу под каким-то логином, а вы пытаетесь ввести другой логин. Это может быть по разным причинам:
- вы зашли в общую базу и пытаетесь войти под своим логином хранилища. Необходимо выяснить логин этой конкретной базы, и заходить под ним, но не переподключать под своим. Посмотреть, под каким логином подключена каждая база может пользователь с административными правами в хранилище, на вкладке "Подключения" окна "Администрирование хранилища конфигурации"
- вы развернули базу, которая уже была подключена к хранилищу. Необходимо отключить конфигурацию от хранилища и подключить заново.
3. Пользователь уже аутентифицирован в хранилище
Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. И с ней работают под этим логином в данный момент.
При такой ошибке вы не сможете подключиться под введенным логином. Необходимо подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.
4. Для данного пользователя уже имеется конфигурация связанная с данным хранилищем конфигурации
Предупреждение похоже на ошибку из предыдущего пункта, но есть небольшое отличие.
Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. Но с ней не работают под этим логином в данный момент.
Предупреждение позволяет подключиться под введенным логином, но нужно понимать последствия. Если вы подключитесь под эти логином, то у другого пользователя рано или поздно возникнет ошибка из предыдущего пункта или аналогичное предупреждение. Рекомендую подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.
5. При получении данных из хранилища или захвате объекта: Не удалось зафиксировать таблицу для чтения "Versions"
Данная ошибка возникает, когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.
Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.
6. При подключении к хранилищу: Не удалось зафиксировать таблицу для чтения "Users"
Данная ошибка может возникать:
- когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.
Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.
- когда в этот самый момент другой пользователь помещает большой объем данных в хранилище
Необходимо подождать, пока другой пользователь закончит помещение объектов в хранилище.
7. Файл не является файлом базы данных
Ошибка соединения с хранилищем конфигурации по адресу:
\\Server\Repository\project1
по причине:
Файл не является файлом базы данных '//Server/Repository/project1/1cv8ddb.1CD'
Данная ошибка может возникать при подключении к хранилищу:
- если есть зависший фоновый процесс к этой базе.
Необходимо зайти в диспетчер задач и принудительно снять зависший фоновый процесс, после этого повторно попробовать подключиться к хранилищу. Если база серверная, то этот процесс может быть зависшим у кого-то, кто работал с базой ранее. Необходимо найти, кто последний работал и попросить почистить у себя в диспетчере зависший процесс.
- если есть зависший сеанс другой базы, подключенной к этому хранилищу на этом компьютере
Так бывает, что одновременно приходится работать с разными базами в одном хранилище. Если про одну базу надолго забыть, и в ней будет появляться ошибка №5, то другую базу с этим хранилищем вы открыть не сможете. Необходимо завершить "забытые" сеансы.
8. Файл базы данных поврежден.
Ошибка соединения с хранилищем конфигурации по адресу:
\\Server\Repository\project1
по причине:
Файл базы данных поврежден '\\Server\Repository\project1\//1cv8ddb.1CD'
Данная ошибка может возникать:
- когда разработчики, подключенные к одному хранилищу, работают на разных версиях платформы и один из них поместил что-то из новой версии платформы.
- когда файл базы данных был действительно поврежден (отключение электричества, скачки напряжения и т.п.)
1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу
2. Почистить кэш хранилища
3. Одному запустить конфигуратор от имени администратора
4. Подключиться к хранилищу
Если указанные действия не помогли, можно воспользоваться утилитой chdbfl.exe, но в моей памяти мне она ни разу не помогла и единственным выходом было создание хранилища с нуля.
9. Неклассифицированная ошибка работы с хранилищем конфигурации
Данная ошибка может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529
1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу
2. Очистить глобальный кэш хранилища
3. Синхронизировать версии платформ.
10. Ошибка "База данных не открыта"
Данная ошибка может возникать при подключении к хранилищу:
- если есть зависший фоновый процесс к этой базе;
- если есть зависшие блокировочные файлы в каталоге хранилища.
1. Если причина в зависших фоновых процессах на локальном компьютере, то лечение как в п.7.
2. Если п.7 не помог, то необходимо всем закрыть конфигураторы, зайти в каталог хранилища, и удалить блокировочные файлы размером 0 байт.
11. Ошибка "Ошибка совместного доступа к хранилищу конфигурации"
При получении данных из хранилища возникает ошибка:
---- Начало операции с хранилищем конфигурации ----
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Ошибка совместного доступа к хранилищу конфигурации:
\\Server\Repository\project1
Не удалось заблокировать таблицу 'OBJECTS'
---- Операция с хранилищем конфигурации отменена ----
Данная ошибка может возникать при получении данных из хранилища:
- если в этот момент с другого компьютера запущен процесс оптимизации хранилища;
1. Дождаться окончания оптимизации хранилища
2. Повторно запросить получение данных из хранилища.
Это, конечно, не весь список ошибок, который может возникать при работе с хранилищем. Я привёл те ошибки, с которыми я лично не раз сталкивался и решал указанными мной способами. Если у вас есть ошибка, которая не описана, и вы знаете способ ее решения, пишите в комментарий, я с удовольствием добавлю информацию в общую статью.
Работа с хранилищем конфигурации
В 1с версии 7.7 совместная разработка или доработка конфигурации была настоящим мучением. Для того чтобы поддерживать одну конфигурацию даже вдвоем, приходилось делать две копии актуальной базы, затем, после внесенных изменений вручную переносить изменения из конфигурации одной копии в конфигурацию другой. Только потом можно было обновить основную поддерживаемую конфигурацию! Усугубляло положение отсутствие подсистем.
В восьмой версии 1с для совместной разработки используется хранилище конфигурации. Работа с хранилищем происходит следующим образом:
Выбираем в меню "Конфигурация"->"Хранилище конфигурации"->"Создать хранилище. "
Указываем путь к каталогу хранилища. (Каталог должен быть доступен для всех разработчиков!)
После того как хранилище создано, заходим в пункт меню "Конфигурация"->"Хранилище конфигурации"->"Администрирование" для того чтобы создать пользователей для разработчиков
. и создаем пользователей
- Подключаем конфигурации разработчиков к хранилищу конфигурации
выбираем пункт меню "Конфигурация"->"Хранилище конфигурации"->"Подключиться к хранилищу. "
Далее конфигуратор нас спросит
Так как у нас с вами копии основной базы пока идентичны, смело нажимаем кнопку "Да" и указываем путь к хранилищу, имя пользователя и пароль
Ждём, пока произойдет сравнение конфигурации с хранилищем.
Если всё прошло успешно, то справа от объектов конфигурации в дереве объектов должна появиться пиктограммка замка.
По умолчанию все объекты конфигурации имеют пиктограммку "замок". Для того чтобы изменить объект конфигурации нужно его захватить, то есть выбрать в контекстном меню объекта пункт "Захватить в хранилище"
указать настройки захвата
У объекта в дереве конфигурации появится пиктограмма
Если объект захвачен другим разработчиком, то объект в дереве конфигурации выглядит так
После того, как нужные изменения внесены, следует объект поместить снова в хранилище со сделанными изменениями. Выбираем в контекстном меню объекта конфигурайции пункт "Поместить в хранилище. "
- Если требуется отменить сделанные изменения и освободить объект от захвата, то выбираем в контекстном меню объекта пункт "Отменить захват"
- Если требуется восстановить объект из хранилища, то то выбираем в контекстном меню объекта пункт "Получить из хранилища. ". При этом внесенные изменения в то время, как объект был захвачен, теряются.
- Так же можно просмотреть историю версий и сравнить захваченный и измененный объект с объектом в хранилище.
- После того, как работа в копиях завершена(или завершен какой-то промежуточный этап), можно обновить конфигурацию основной базы для этого нужно выбрать пункт в меню "Конфигурация"->"Хранилище конфигурации"->"Обновить конфигурацию из хранилища" или "Конфигурация"->"Хранилище конфигурации"->"Сравнить/объединить конфигурацию с хранилищем".
Во втором случае произойдет более "мягкое" обновление конфигурации, то есть, можно будет посмотреть отчет по различиям объектов исходной конфигурации и хранилища.
Приятной вам разработки!
Каждая из типовых конфигураций 1С имеет свою собственную внутреннюю структуру и требует точных знаний особенностей настройки системы.
Для настройки 1С 8 заказчик составляет перечень требований, куда входят необходимые ему функции и наборы инструментов.
1Скрипт-менеджер
Выгрузка и загрузка данных. 1С7.7
Конфигурация IT-сервис.(Управляемое приложение)
Выгоняем пользователей из серверной информационной базы
Для проведения регламентных работ в информационной базе 1С:Предприятия 8 часто необходимо получить монополный доступ к базе. Например, для выполнения бэкапа базы или выполнения регламентных работ на сервере СУБД (реиндексация и т.д.), необходимо отключить все активные сеансы.
Рассмотрим простой способ отключения пользователей от информационной базы с помощью стандартного функционала сервера 1С:Предприятия.
Стандартный функционал
Сразу оговорюсь, что речь будет идти о клиент-серверном варианте работы 1С:Предприятия 8. Для отключения сеансов зайдем в консоль администрирования сервера. Там найдем нужную информационную базы в списке:
Зайдя в свойства ИБ установим опцию "Блокировка начала сеансов включена". При этом может быть необходимо ввсетси логин/пароль учетной записи администратора информационной базы.
Не забывайте установить период блокировки сеанса. Также следует предусмотреть, что на время блокировки сеансов нужно остановить все фоновые задания. Делается это опицей "Блокировка регламентных заданий включена".
Код разрешения можно использовать для входа в информационную базу для выполнения регламентных работ, пока остальные сеансы не активные. Вводить код разрешения при подключении к базе нужно с помощью параметров. Например, так будет выглядеть параметр, переданный серверу, если код разрешения "123456".
Войдя в базу таким способом мы получим монополный доступ к информационной базе. Другие сеансы не смогут к нам присоединиться.
По началу периода блокировки сеансов сначала появляется уведомление:
После сеанс завершается.
Активные сеансы также можно отключить, удалив их из списка активных сеансов. Подобное действие порой необходимо для завершения зависших сеансов.
На практике об отключении пользователей лучше сообщать заранее, чтобы снизить риски потери данных, введенных пользователями, но еще не сохраненных.
Непонятное для пользователей, а иногда и начинающих программистов, слово "регистры". Попытаемся раскрыть его в этой статье. Рассмотрим устройство регистров накопления.
Для получения доступа к обновлениям конфигураций 1С 8.2 фирма 1С выпускает диски информационно-технического сопровождения (ИТС)
Выгрузка прайс-листа 1С 7.7 в Excel
Доступ к реквизитам справочника в 1с7.7 для каждого пользователя
Печать ценников для УТ 10.3 платформа 8.2 на две цены (розничная и оптовая)
Читайте также: