Ошибка в работе приложения не задан уровень доступа
Возникает, когда программе не удается подключиться к ключу защиты.
В случае с локальным ключом :
В случае с сетевым ключом :
На компьютере, где установлена программа :
На компьютере (сервере), где установлен сервер сетевого ключа:
Решение.
Для локального ключа :
1. Проверить наличие ключа защиты в USB-порту.
2. Переставить ключ защиты в другой USB-порт. При наличии возможности проверить воспроизводимость ошибки с другим ключом.
Для сетевого ключа :
На компьютере, где установлена программа:
1. Проверить состояние службы «Sentinel LDK License Manager», при необходимости запустить вручную. Для автоматического запуска службы тип запуска должен быть «Автоматически».
2. Проверить настройку поиска ключа в соответствии с инструкцией «Настройка поиска ключей в "Sentinel Admin Control Center"».
На компьютере (сервере), где установлен сервер сетевого ключа:
3. Проверить наличие ключа защиты в USB-порту. При необходимости переставить ключ в другой USB-порт. При наличии возможности проверить воспроизводимость ошибки с другим ключом.
4. Произвести установку драйвера сетевого ключа согласно инструкции «Установка сервера сетевого ключа» и выполнить проверку доступности ключа.
5. Проверить состояние службы «Sentinel LDK License Manager», при необходимости запустить вручную. Для автоматического запуска службы тип запуска должен быть «Автоматически».
6. Убедиться, что доступ к серверу сетевого ключа по сети не блокируется антивирусом или сетевым экраном (например брандмауэром Windows) и выполнить проверку доступности ключа.
1.1.2. Ошибка чтения данных из ключа: Приложение не может быть запущено
Возникает, когда программе не удается зачитать данные ключа защиты.
В случае с сетевым ключом :
Неправильно указан адрес сетевого ключа для данного экземпляра программы.
Решение.
1. На компьютере, где установлена программа, произвести настройку поиска ключа в соответствии с инструкцией «Настройка поиска ключей в "Sentinel Admin Control Center"».
2. После этого выполнить проверку доступности ключа Sentinel HL.
3. Файл « HASPConfig.xml » в каталоге «Файлы лицензий и настроек» данного экземпляра программы должен содержать точно такой же адрес сетевого ключа, какой указан в «Sentinel Admin Control Center».
Перейти в каталог можно с помощью программы «Пути к папкам приложения».
1.1.3. Unknown error (H0027)
Возникает при запуске программы с локальным ключом через протокол RDP (Подключение к удаленному рабочему столу).
Решение.
Локальный ключ не поддерживает работу по RDP (Подключение к удаленному рабочему столу). Варианты решения зависят от типа лицензии.
Если лицензия А0 «Персональная», в этом случае:
1. Вы можете забрать ключ домой и установить с ним программу на своем домашнем компьютере, затем выполнить перенос данных с рабочего компьютера.
2. Если вы сотрудник организации и локальных ключей у вас более одного, вы можете воспользоваться платной услугой «Объединение локальных ключей в 1 сетевой» со сменой лицензии на «Корпоративная», обратившись к поставщику программы.
Если лицензия А0 «Корпоративная» и ключ вставлен в вашем компьютере (локальный):
1. Вы можете забрать ключ домой и установить с ним программу на своем домашнем компьютере, затем выполнить перенос данных с рабочего компьютера.
2. Вы можете воспользоваться услугой «Перевод локального ключа в сетевой на 1 рабочее место», обратившись к поставщику программы.. Услуга оказывается только в рамках действующего ГО.
На скриншотах ниже показан состав компонентов и уровень доступа выбранного ключа.
Например, для локального ключа доступ только "Лок." – локальный.
Для сетевого ключа доступ "Лок." – локальный, "Удал." – удаленный и "Терм." – терминальный (RDP).
1.1.4. Ошибка чтения данных из ключа: Невозможно определить наличие ключа. Возможно, не установлен драйвер или отсутствует необходимая библиотека. Приложение не может быть запущено
Возникает при запуске программы, если в системе отсутствует служебный файл «hasp_windows_2152288.dll».
Решение.
Для восстановления файла «hasp_windows_2152288.dll» необходимо:
2. Извлечь из архива файл «hasp_windows_2152288.dll».
3. Поместить извлечённый файл в папку «C:\Windows\system32», для выполнения этой операции потребуются права администратора компьютера.
1.1.5. Функция не найдена (H0031)
Возникает при запуске программы, если в используемом ключе эта программа отсутствует.
Может возникнуть в случае наличия и использования нескольких ключей с разным набором продуктов.
Решение.
Для локального ключа :
Проверить, что к USB-порту подключен требуемый и единственный ключ защиты.
Для сетевого ключа :
На компьютере, где установлена программа, убедиться, что поиск ключа настроен правильно.
Для этого проверить настройку поиска ключа в соответствии с инструкцией «Настройка поиска ключей в "Sentinel Admin Control Center"».
1.1.6. Unknown error (H0038)
Возникает при запуске программы, когда количество пользователей, подключенных к ключу защиты, превышает лимит рабочих мест продукта в ключе.
Решение.
Для сетевого ключа:
Лимит рабочих мест продукта в ключе указан в столбце « Лимит». Количество текущих подключений продукта к ключу - в столбце « Сеансы» .
По кнопке «Сеансы» в конце строки можно посмотреть подробности всех подключений.
1.2. Ошибки ключа защиты CodeMeter
1.2.1. Ошибка: Невозможно определить наличие ключа: Ошибка чтения данных из ключа: Не найдена запись в CMContainer, ошибка 200. Приложение не может быть запущено.
Возникает, когда программе не удается подключиться к ключу защиты.
В случае с локальным ключом :
В случае с сетевым ключом :
Решение.
Для локального ключа :
1. Проверить наличие ключа защиты в USB-порту.
2. Переставить ключ защиты в другой USB-порт. При наличии возможности проверить воспроизводимость ошибки с другим ключом.
3. Убедиться, что драйвер ключа установлен и отображается в перечне установленных программ и компонентов Windows, пункт «CodeMeter Runtime Kit v*.*».
Исправный ключ при наличии драйвера должен отображаться в «Диспетчере устройств» Windows, в категории «Дисковые устройства», как «WIBU - CodeMeter-Stick USB Device» без восклицательных или предупреждающих знаков.
При необходимости переустановить драйвер ключа.
Для сетевого ключа :
1. На компьютере (сервере), где установлен сервер сетевого ключа, выполнить рекомендации данные выше для локального ключа.
2. Убедиться, что служба сервера сетевого ключа запущена. Проверить состояние службы можно по инструкции.
3. Убедиться, что доступ к серверу сетевого ключа по сети не блокируется антивирусом или сетевым экраном (например брандмауэром Windows). Проверить доступность ключа CodeMeter можно по инструкции.
1.2.2. Ошибка: Файл лицензии "C:\ProgramData\InfoStroy\A0\A0win1\bin\0000xxxx.ISL" не обнаружен. Приложение не может быть запущено.
Возникает, когда в указанном каталоге отсутствует файл лицензии для найденного ключа защиты.
Решение.
1. Перейти в каталог «Bin» по пути, указанному в тексте ошибки.
2. Скопировать в каталог «Bin» необходимые файлы лицензии.
1.2.3. Ошибка! Ключ защиты недоступен или на ключе нет свободных рабочих мест. Проверьте доступность ключа и наличие свободных рабочих мест.
Решение.
Для локального ключа :
Для дальнейшей работы подключите ключ защиты и нажмите «Повтор». Если ошибка повторяется и вы не знаете, что с ключом, то сохраните изменения и закройте программу. Затем обратитесь в техническую поддержку поставщика.
Для сетевого ключа :
Для дальнейшей работы нажмите «Повтор». Если ошибка повторяется — нажмите «Пропустить», сохраните изменения и закройте программу. Затем обратитесь к вашему Администратору сети.
1.2.4. Ошибка: Файл лицензии "C:\ProgramData\InfoStroy\A0\A0win1\bin\0000xxxx.ISL" поврежден -IEO. Приложение не может быть запущено.
Данная ошибка может возникнуть после замены файла лицензии.
Решение.
Для решения этой ошибки необходимо обращаться в службу технической поддержки Компании ИнфоСтрой.
1.2.5. Отсутствует драйвер ключа защиты. Запуск программы невозможен.
Решение.
1. Запустить системную службу CodeMeter.
Запуск службы возможен только от имени учетной записи с правами администратора на этом компьютере.
Способ 1: Запуск службы будет произведен автоматически при запуске «CodeMeter Control Сenter», открыть который можно из контекстного меню значка «CodeMeter Control Сenter» в панели задач.
На запрос контроля учетных записей необходимо ответить «Да».
Способ 2: Запуск службы можно произвести вручную из окна «CodeMeter Control Сenter». Для этого в главном меню выбрать пункт «Выполнить» > «Запустить системную службу CodeMeter»
Во избежание подобных ошибок в будущем следует убедиться, что служба «CodeMeter Runtime Server» имеет тип запуска «Автоматически» и будет запускаться самостоятельно при загрузке компьютера.
2. Убедиться, что драйвер ключа установлен и отображается в перечне установленных программ и компонентов Windows, пункт «CodeMeter Runtime Kit v*.*».
При отсутствии драйвера ключа его необходимо установить по инструкции «Установка драйвера ключа CodeMeter».
Если драйвер ключа установлен, но ошибка остается, его следует удалить и заново установить по инструкции.
Если программа работала с сетевым ключом «CodeMeter», необходимо дополнительно указать адрес сервера сетевого ключа в «CodeMeter WebAdmin». Как это сделать описано в п. 2.1. инструкции по переносу ключа «CodeMeter».
1.3. Ошибки ключа защиты Sentinel
1.3.1. E0003(E004A) - ключ защиты не найден
Возникает, когда программе не удается подключиться к ключу защиты.
В случае с локальным ключом :
В случае с сетевым ключом :
Решение.
Для локального ключа :
1. Проверить наличие ключа защиты в USB-порту.
2. Переставить ключ защиты в другой USB-порт. При наличии возможности проверить воспроизводимость ошибки с другим ключом.
3. Убедиться, что драйвер ключа установлен и отображается в перечне установленных программ и компонентов Windows, пункт «Sentinel Protection Installer» (например, «Sentinel Protection Installer 7.6.9»).
Исправный ключ при наличии драйвера должен отображаться в «Диспетчере устройств» Windows, в категории «Контроллеры USB», как «SafeNet USB SuperPro/UltraPro» без восклицательных или предупреждающих знаков.
При отсутствии драйвера локального ключа «Sentinel» следует установить его по инструкции «Установка драйвера для локального ключа Sentinel». При необходимости переустановить драйвер ключа выполнить действия по инструкции «Переустановка драйвера ключа Sentinel».
4. Запустить программу с локальным ключом (тип AllModes) без использования терминального режима. Для работы в терминале необходим сетевой ключ.
Для сетевого ключа :
1. Для работы с сетевым ключом необходимы права на изменение файла «SntlConfig.xml» для текущего пользователя (файл расположен в двух папках: «Система» и «Утилиты» программы «Пути к папкам приложения»).
2. На компьютере (сервере), где установлен сервер сетевого ключа, выполнить рекомендации данные выше для локального ключа.
3. Убедиться, что служба сервера сетевого ключа запущена.
4. Убедиться, что доступ к серверу сетевого ключа по сети не блокируется антивирусом или сетевым экраном (например брандмауэром Windows). Проверить доступность ключа «Sentinel» можно по инструкции.
5. Проверить, что количество свободных рабочих мест запускаемой программы на сетевом ключе не исчерпано. Как это сделать описано в инструкции Проверка доступности сетевого ключа Sentinel.
1.3.2. Ошибка получения информации о версии ключа.
Возникает по нескольким причинам:
В случае с локальным ключом :
В случае с сетевым ключом :
Решение.
1. Перейти в список служб ОС Windows и найти службы с наименованиями:
- «Sentinel Keys Server»;
- «Sentinel Protection Server»;
- «Sentinel Security Runtime».
Остановить указанные службы и выставить тип запуска в значение "Отключено". Более правильное решение - выполнить изменение компонентов драйвера локального ключа «Sentinel».
2. Проверить наличие файла библиотеки «sx32w.dll» в системной папке:
C:\Windows\System32\ - для 32-х разрядной системы
или C:\Windows\SysWOW64\ - для 64-х разрядной системы.
При отсутствии данной библиотеки на компьютере ключ «Sentinel» не может прочитать файл лицензии, выдавая ошибку:
Убедиться, что версия библиотеки «sx32w.dll» соответствует версии драйвера «Sentinel», установленного на компьютере (сервере).
При необходимости заменить библиотеку «sx32w.dll» на нужную версию. Обе версии по-умолчанию входят в поставку, одна из них имеет название sx32w_.dll .
Версию драйвера «Sentinel» можно проверить в списке установленных программ компьютера, пункт «Sentinel Protection Installer» (например, «Sentinel Protection Installer 7.6.9»).
Настройка прав доступа - одна из самых распространенных задач для разработчиков 1С. Это не значит, что подобные задачи всегда ставятся явно. Большая часть из них связаны с текущей разработкой, ведь новый функционал требует ограничений на использование среди пользователей. Но есть и исключения, когда поступает заказ / задача по ограничению доступа к некоторым данным или функциям в информационной базе.
Очень часто можно столкнуться с ситуацией, когда после "горячего" внедрения новой системы у большого количества пользователей имеются полные права. То есть пользователей с возможностями администратора информационной базы слишком много. Как результат - множество ошибок в данных, коллизии в настройках учета, странное поведение системы и непредсказуемые результаты отчетов. Великолепно, не правда ли?
Есть и другие истории, когда с правами все в порядке. Есть толковый администратор, который следит за корректностью их настройки. И все работает какое-то время, пока в дело не вступают разработчики (штатные или с аутсорсинга, не важно!). Множество задач, множество требований, множество ошибок с правами. Такова печальная картина.
Конечно, я дал немного пессимистичную оценку, чтобы подготовить Вас к незабываемому путешествию по типичным ошибкам разработки прав доступа. Мы пройдемся по самым частым проблемам, с которыми приходилось сталкиваться. Это не полный список, поэтому Ваши истории также приветствуются в комментариях.
Обычный процесс разработки
Прежде чем перейти непосредственно к ошибкам, давайте вспомним обычный процесс разработки прав доступа. Все основные настройки доступа выполняются с помощью ролей. Роли - объекты конфигурации, занимающие центральное место в построении модели этих самых прав. Именно с их помощью разработчик может настроить доступ к объектам конфигурации. Они же применяются для более гибкой настройки с помощью разграничений на уровне записей (RLS).
Именно с помощью ролей можно добиться приемлемого результата в части разграничений доступа, но не всегда. Если стандартных возможностей этого объекта недостаточно, то в дело вступают различные дополнительные функции, которые добавляют сами разработчики: регистры дополнительных прав, различные запреты с помощью подписок на события и многое, многое другое.
Поскольку мы говорим о самых частых ошибках, то упор будет делаться именно на роли, т.к. именно они являются самым универсальным и простым решениям для большинства задач по правам.
Внезапные проблемы
Итак, поехали! Какие же ошибки могут быть с правами доступа при разработке?
Просто новый объект
Представьте, что к Вам поступил заказ от клиента: создать новый документ в системе для внесения некоторого пакета документов. Другими словами, нужно добавить документ, который хранит ссылки на другие документы и т.д. Задача ясна. День разработки, после демонстрация клиенту (проверял сам директор!) и можно выкладывать в рабочую систему. Перед обновлением сделаны рассылки, что новый функционал заработает с такого-то числа. Наступает день "икс", Вы вечером обновляете базу и с чувством выполненного долга уходите на сон.
Но утром Вас ждет сюрприз! Никто, кроме директора и системного администратора (да, да! он там главный по 1С) не могут получить доступ к новому документу. В интерфейсе его просто нет!
Догадались в чем дело? Ну, конечно! Новый документ добавлен, функционал отлично разработан, но права на него никто не предоставил.
Следовать лозунгу: "Добавил объект - проверь права!".
А еще лучше - написать Unit-тест, который будет проверять объекты без прав доступа. Посмотрите в сторону
Давать права с разумным подходом.
В типовых конфигурациях давно есть разграничения по профилям доступа, группам доступа. С их помощью можно настраивать права быстро и эффективно.
При добавлении новых объектов не стоит делать ставку на роль "Полные права". Нужно либо добавлять новый объект в существующие роли, либо добавлять новые роли. Все же очевидно.
Скроем подсистему
Пришла срочная задача - нужно части пользователей скрыть подсистему "Супер подсистема увеличения продаж".
Проблема в том, что конфигурация наполнена legacy-кодом, а роли конфигурации не имеют четких ограничений между подсистемами. Все связано как какое-то спагетти. А сделать надо еще вчера (ну, Вы понимаете)!
Выпив 3 кружки кофе, решение приходит само. Нужно лишь скрыть всем ролям доступ к этой подсистеме. Именно подсистеме как объекту конфигурации, а все входящие в ее состав объекты вообще не трогать. Только не забыть дать доступ к этой подсистеме для нужной роли (ее даже можно создать отдельно ради такого случая). Гениально!
Есть еще другой путь - доступ на подсистему не менять, а изменить видимость по умолчанию в настройках.
Это будет работать. У вас даже могут принять работу, и Вы разойдетесь с заказчиком рукопожатием. НО! Вы сделаете не разграничение прав доступа, а лишь измените видимость элементов интерфейса. Да, в первом случае доступа к объекту подсистемы не будет, но к объектам из его состава - пожалуйста! Например, в подсистеме был документ "СекрентныйДокумент". Вы идете вот сюда, нажимаете "Перейти по навигационной ссылке" и вводите примерно такую строку.
Имя документа должно быть таким же как в конфигураторе, тогда все сработает. Все! Список документов, доступ к которым нам ограничили, мы открыли. А дальше работаем как нам нужно.
Вариант с настройкой видимости подсистемы еще проще: заходим в настройки интерфейса и включаем видимость для нужной подсистемы.
Как оказалось, права доступа мы и не настроили.
Для того, чтобы не столкнуться с такой ситуацией достаточно запомнить, что настройки видимости подсистем и настройки видимости на объекты подсистемы - это не права доступа. Это лишь ограничения / настройки интерфейса. А ограничивать доступ к данным с помощью интерфейса - это последнее дело при разработке.
Реквизит больше недоступен
Иногда можно столкнуться с задачей - запретить некоторым пользователям просматривать / изменять определенный реквизит у объекта. В ролях можно настраивать "доступ" к отдельным реквизитам.
"Это так круто!", можно услышать от некоторых разработчиков. Действительно, поставил нужные чек боксы и вперед - задача решена!
Вот только есть один нюанс - к правам доступа эти возможности не имеют никакого отношения. Как и в прошлом примере, все это интерфейсные настройки. Например, если ограничить доступ к реквизиту с помощью роли, то прочитать его все равно будет можно с помощью обычных запросов.
А если данные таким способом можно прочитать, то о каком разграничении доступа может идти речь.
Не используйте эти настройки для решения задач с правами доступа. Это интерфейсные функции.
Для разграничения доступа на изменение реквизитов Вы можете использовать проверки заполнения, события объектов (перед записью, при записи, обработка проведения и др.), в которых реализуете проверки программно. Запретить же просмотр отдельных реквизитов объекта эффективно практически невозможно. Только если дорабатывать все возможные формы, отчеты и другие места конфигурации, добавляя проверки на доступ к нему. Но вот сопровождать такое я бы не взялся.
Есть другой эффективный способ - вынести реквизит в отдельную таблицу и настраивать доступ на нее. Но это уже совсем другая история.
Видимость команд
Выше мы настраивали видимость подсистем. Как уже было сказано, решать так задачи с правами смысла нет, т.к. права на самом деле и не изменяются. По такому же принципу часто поступают не с подсистемами целиком, а с отдельными командами или объектами.
Как и в прошлый раз, по умолчанию пользователь не будет видеть команды в интерфейсе. Но что ему мешает сделать так.
Фиаско? Еще какое!
Повторюсь: настройка видимости и настройка прав доступа - совершенно разные вещи. Никогда не пытайтесь решить вопросы прав доступа с помощью настроек интерфейса.
Новая роль
Выстроенная ролевая модель, четкое разграничение прав доступа. грамотно настроенный RLS! Ваша система эталон работы с правами. И оно понятно, ведь информация в ней чувствительная, ведь это отдел казначейских операций. Сотрудники одного отдела не должны видеть операции соседних подразделений и наоборот. В общем, безопасность на высшем уровне!
Но вот однажды, выпуская новую задачу в рабочую базу, что-то пошло не так! После обновления ВСЕ пользователи стали видеть все заявки, хотя изменения в существующие правила RLS никто не вносил. Что же произошло?
Как Вы догадались - была добавлена новая роль. Нет нет, роль имеет настройки доступа только для тех объектов, для которых действительно нужно. В том числе и для объектов с той самой чувствительной информацией. Вот только есть одна проблема: при добавлении новой роли никто в ней не описал правила RLS, в итоге он перестал работать для всех кому эту роль добавили (в нашем примере ее, допустим, добавили большинству сотрудников).
Как известно, пользователь получает максимальный доступ, который ему предоставляют роли. В нашем случае роль без RLS дает больше прав, чем остальные. Вот платформа их и применяет.
Как же такое вообще можно предотвратить?
Вообще, если в системе есть RLS, то это дополнительная ответственность для разработчиков:
- Нужно корректно писать запросы
- Необходимо учитывать это в отчетах
- При добавлении ролей нужно добавлять правила RLS (это как раз наш случай)
- Некоторый код не будет работать с RLS совсем (например, некоторые приемы с объектной техникой работы с данными, или вложенные подзапросы большой глубины и т.д.).
- И др.
Так что тут можно посоветовать быть более внимательным и писать Unit-тесты для проверки прав доступа.
RLS не наша тема
Информация выше Вас напугала и теперь использовать RLS никогда не будете? Есть способ проще! Можно в динамических списках, отчетах и других местах подбора данных программно устанавливать отборы на получаемую информацию. Например, добавить ограничения по организации. Вот такой код в событии "При создании на сервере" решает эту задачу.
И ведь все работает! Но раз уж этот подход попал в статью, значит не все так гладко. Проблема в том, что ограничения доступа к данным здесь нет, есть только интерфейсные ограничения. Этот подход еще можно назвать как "костыльный RLS". Его обычно применяют, когда задачу надо сделать еще месяц назад, а в ИТ-отдел уже ломятся сотрудники с требованием ограничить доступ.
Проблема в том, что есть множество других путей получить доступ к этим данным. Предусмотреть все возможные ограничения с помощью программных "костылей" невозможно. Например, пользователь вывел отчет, а в него попал "запретный" документ. Ничто не мешает нам его открыть. Слышу вопрос: "Так в форме документа тоже можно сделать программную проверку при открытии!?". Конечно можно! Но что мне мешает в отчете вывести интересующие меня данные из документа с помощью СКД.
Все защиты пали! А как жаль, ведь потрачены десятки часов работы.
И опять, все это интерфейсные настройки. Зачем заниматься этим, если нужно ограничивать права доступа?
Сроки горят? Отлично, "костыль" оправдан! Только не забудьте вернуться к этому вопросу в будущем.
Я сам настрою
И на последок еще один небольшой "фейл". Иногда в системе имеется дополнительный функционал настройки доступа. Например, регистр сведений "Дополнительные права", в котором каждому пользователю добавляются отдельные функции.
Не раз приходилось сталкиваться с такой ситуацией, что права все настраиваются и все работает. Гибкие настройки - мечта администратора и все такое. Но.
У пользователей тоже есть доступ к этому регистру! Причем у всех и на изменение. Да, этот регистр может быть не выведен явно в интерфейс, но это не гарантия того, что любопытные коллеги будут исследовать информационную систему и найдут эту пасхалку. А раз так, то выдать им себе дополнительные права не составит проблем.
Вывод простой: создавая инструменты управления доступом, не забудьте разграничить доступ на этот инструмент.
На самом деле
Это далеко не полный список потенциальных ошибок. Скорее это самые простые, распространенные и банальные ситуации. Возможно, Вы уже знакомы с некоторыми из них. Какие-то допускали Ваши коллеги, какие-то коллеги коллег, но точно не Вы!
Скажу Вам по секрету, только никому не рассказывайте: за все время работы с платформой 1С и решениями на ее основе автором были сделаны все перечисленные ошибки. И даже больше!
Но если бы не было ошибок, то и опыта бы не было. А также этой публикации :)
Способ 1: Запуск от имени администратора
Самое простое и быстрое решение – это произвести запуск инсталлятора игры от имени администратора. Необходимо выполнить простые действия:
Выполнив эти шаги, программное решение успешно запуститься.
Хочется отметить, что существует софт, которому для запуска необходимы права администратора. Иконка такого объекта будет иметь пиктограмму щита.
Способ 2: Доступ к папке
Пример, который был приведен выше, показывает, что причина неисправности кроется в отсутствующем доступе к директории временных данных. Программное решение хочет воспользоваться временной папкой и не может получить к ней доступ. Так как изменить приложение нет возможности, то необходимо открыть доступ на уровне файловой системы.
Способ 3: Учетные записи пользователей
Проблема может быть устранена изменением параметров учетной записи. Для этого необходимо выполнить следующие шаги:
-
Совершаем переход по пути:
Должно выглядеть вот так.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Область применения ЭП довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью: Госуслуги, онлайн-сервисы для управления средствами в банке и электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭП, могут вызвать различные серьёзные: от упущенной выгоды до материальных убытков.
Какие бывают ошибки
Проблемы при использовании ЭП, с которыми пользователи встречаются чаще всего, можно условно разделить на три группы:
Проблемы с сертификатом Они появляются, когда сертификат не выбран, не найден или не верен.
Проблемы с подписанием документа. Ошибки возникают при попытке подписать документ.
Проблема при авторизации на торговых площадках.
Рассмотрим неполадки подробнее и разберёмся, как их решать.
Сертификат не найден
Иногда при попытке подписать электронный документ с помощью ЭП пользователь может столкнуться с ошибкой «Не удалось найти ни одного сертификата, пригодного для создания подписи»
У подобных ошибок могут быть следующие причины:
1. На компьютере не установлены корневые сертификаты Удостоверяющего Центра (УЦ), в котором была получена ЭП. Необходимо установить либо обновить корневой сертификат. Установка корневых сертификатов удостоверяющего центра подробно описана в нашей инструкции.
2. На ПК не установлено ни одного личного сертификата ЭП. Для применения ЭП необходимы и личные сертификаты. Об их установке мы писали в другой статье.
3. Установленные на компьютере необходимые сертификаты не валидны. Сертификаты отозваны или просрочены. Уточните статус сертификата в УЦ. Ошибка с текстом «Ваш сертификат ключа подписи включён в список отозванных» возникает, если у сертификата закончился срок действия или на ПК нужно обновить список сертификатов. В последней ситуации следует вручную загрузить перечень отозванных сертификатов.
Для установки списка отозванных сертификатов:
Откройте личный сертификат пользователя в окне Свойства браузера. Чтобы открыть его, наберите «Свойства браузера» в поисковой строке меню Пуск. Перейдите во вкладку Содержание и нажмите кнопку «Сертификаты».
Во вкладке Состав выберите из списка пункт «Точки распространения списков отзыва».
В блоке Имя точки распространения скопируйте ссылку на загрузку файла со списком отзыва.
Скачайте по указанной ссылке файл. Нажмите по нему правой кнопкой мыши и выберите в контекстном меню «Установить список отзыва (CRL)».
Следуйте указаниям «Мастера импорта сертификатов».
Не виден сертификат на носителе
Как правило, причина такой проблемы — сбой в работе программных компонентов. Для её решения достаточно перезагрузить компьютер. Однако иногда этого бывает недостаточно, поэтому требуется переустановка драйверов или обращение в службу техподдержки.
К наиболее распространённым причинам такой проблемы относятся следующие случаи:
Драйвер носителя не установлен или установлен некорректно. Для решения проблемы необходимо извлечь носитель электронной подписи из ПК и скачать последнюю версию драйвера носителя с официальных ресурсов. Если переустановка драйвера не помогла, подключите носитель к другому ПК, чтобы убедиться в исправности токена. Если токен определится другой системой, попробуйте удалить на неисправном компьютере драйвер носителя и установить его заново.
Долгое опознание носителя. Для решения проблемы необходимо дождаться завершения процесса или обновить версию операционной системы.
Некорректная работа USB-порта. Подключите токен к другому USB-порту, чтобы убедиться, что проблема не в носителе ЭП. Если система определила токен, перезагрузите компьютер. Если это не поможет, следует обратиться службу технической поддержки.
Неисправность носителя. Если при подключении токена к другому компьютеру или USB-порту система не определяет его, значит, проблема в самом носителе. Устранение неисправности возможно в данном случае лишь одним путём — нужно обратиться в сервисный центр для выпуска нового носителя.
ЭП не подписывает документ
Причин у подобной проблемы множество. Среди самых распространённых можно выделить следующие неполадки:
Закрытый ключ на используемом контейнере не соответствует открытому ключу сертификата. Возможно был выбран не тот контейнер, поэтому следует проверить все закрытые контейнеры на компьютере. Если необходимый контейнер по тем или иным причинам отсутствует, владельцу придётся обращаться в удостоверяющий центр для перевыпуска ЭП.
Ошибка «Сертификат недействителен» (certificate is not valid). Следует повторно установить сертификат ЭП по инструкциям УЦ в зависимости от используемого криптопровайдера — КриптоПро CSP, ViPNet CSP или другого.
Сертификат ЭП определяется как непроверенный. В этом случае необходимо переустановить корневой сертификат удостоверяющего центра.
Истёк срок действия криптопровайдера. Для решения этой проблемы необходим новый лицензионный ключ к программе-криптопровайдеру. Для его получения необходимо обращаться к специалистам УЦ или к ответственным сотрудникам своей организации.
Подключён носитель с другим сертификатом. Убедитесь, что подключён правильный токен. Проверьте также, не подключены ли носители других сертификатов. Отключите другие носители в случае их обнаружения.
В момент подписания электронных документов или формирования запроса в различных может возникнуть ошибка «Невозможно создание объекта сервером программирования объектов».
В этой ситуации помогает установка и регистрация библиотеки Capicom:
Распакуйте и переместите файлы capicom.dll и capicom.inf в каталог syswow64, находящийся в корневой папке ОС.
Откройте командную строку от имени администратора — для этого в меню Пуск наберите «Командная строка», нажмите по найденному приложению правой кнопкой мыши и выберите Запуск от имени администратора.
Введите «c:\windows\syswow64\regsvr32.exe capicom.dll» (без кавычек) и нажмите ENTER. Должно появиться уведомление о том, что команда выполнена успешно.
Выбранная подпись не авторизована
Процесс запроса на авторизацию ЭП на разных торговых площадках может отличаться: часто нужно отправлять запрос оператору системы на авторизацию, иногда рабочее место настраивается автоматически.
Если ошибка сохраняется, возможно, следует отключить защитное ПО или добавить сайт электронной площадки в исключения.
Если ваша проблема с электронной подписью не решена, но обратитесь к нашим специалистам техподдержки.
Читайте также: