Глеб, добрый день!
Подскажите, пожалуйста. Мне нужно подобрать сетевой контроллер доступа, к которому я бы мог подключаться из собственного программного обеспечения. В общих чертах, чтобы я мог со своего linux-сервера отправить команду контроллеру на открытие определенной двери. Желательно, чтобы интерфейс взаимодействия был HTTP (JSON/XML/SOAP и пр...) или хотя бы TCP/IP. Большинство предлагаемых контроллеров работают со своими тяжеловесными серверами, которые для моей задачи избыточны.
Можете ли что-то порекомендовать?
Андрей, без шуток, если вы это сделаете, я Вам буду бесконечно признателен, ибо до сих пор никакого подтверждения, что закрытый код надежно защищает исходники у меня нет.
Если у кого-то получится его открыть, то и в паблик выкладывать его закрытым смысла нет. Я тогда просто выложу его открытым как есть.
Ваше замечание полностью уместно. Однако оно относится скорее не к расширению, а вообще к механизму web-сервисов. Полагаю, в этом случае имеет смысл ориентироваться все же на количество одновременных соединений.
Ведь если пользователь сайта, например, увидел на сайте цену на товар, взятую из 1С, то его вряд-ли можно назвать пользователем программы 1С.
Однако, если создать приложение, которое подменяет пользовательский интерфейс 1С, полагаю тут уже будет нарушение.
EnterpriseData используется только в шести типовых конфигурациях и позволяет обмениваться данными только об определенных объектах. Если его пихать в свою отраслевую конфигурацию, то еще на стороне 1С придется повозиться. То есть это достаточно узкая штука. Но я согласен, что по возможности лучше использовать его, т.к. это стандарт.
Давайте лучше решим практическую задачу. Вы заходите в расширение в дерево конфигурации, выделяете тот метод, который кажется вам небогоугодным и нажимаете кнопку «Delete». После этого расширение становится безопасным, можно его даже под своей редакцией выпустить.
А остальные пользователи не нажимают эту кнопку и радуются тому, что у них есть возможность писать уязвимости.
1. Лицензия MIT регулирует лишь права на использование программного обеспечения в том виде, в котором оно предоставляется. Про исходники в нем не упоминается.
Код пока закрыт только в расширении которое можно ставить в безопасном режиме, в клиентских библиотеках код НЕ защищен.
2. Само расширение в первую очередь предназначено для сервер-серверного взаимодействия между известными надежными узлами. Эту опцию Вы можете использовать для отладки и запретить на уровне ролей доступа на сервере 1С в рабочем проекте.
3. Накидать можно все что угодно, а можно уже накиданное взять.
Первое:
Это все верно, если у Вас есть популярная публичная система, и Вам необходимо предоставить доступ неограниченному количеству разработчиков заранее неизвестных. Здесь я с Вами абсолютно согласен, предоставлять им гибкий доступ к системе неприемлемо.
Но чаще всего доступ к системе нужен не публичный, а для конкретного приложения, которое может разрабатываться той-же командой разработчиков для нужд той-же организации, которая использует 1С. Например, когда нужен внутренний портал с ограниченным доступом к данным из 1С, или какое-то специфическое приложение для внутренних сотрудников. В этом случае обе системы по сути являются частью единой более сложной системы и, скорее всего, расположены либо на одном сервере либо в изолированной корпоративной сети. В этом случае гибкий доступ к данным, может быть востребован, т.к. интегрируемому приложению Вы заранее доверяете.
Само описание пакетов не дает вам гарантии, что сервис работает корректно, т.к. нужно чтобы разработчики сервиса поддерживали его в актуальном состоянии, соответствующем имеющемуся описанию. В этом плане ничего не мешает создать интерфейсные методы в 1С на естественном для 1С языке и вызывать их удаленно через Бром (на низком уровне это будет тот же самый SOAP/XSD/XDTO, он описан в документации). Так же как и в первом случае эти методы придется актуализировать при обновлении системы. Разница только в том, что не придется программировать формирование XDTO-пакеты, т.к. упаковку и распаковку XDTO пакетов расширение делает автоматически.
Второе:
Вызов произвольного кода можно запретить (точнее не разрешать). Под клиентским приложением подразумевается серверная часть стороннего приложения, которому Вы доверяете (по отношению к 1С оно — клиент), возможно вы его сами и разрабатываете. Естественно, конечному клиенту не следует как либо взаимодействовать вообще с этим расширением напрямую из пользовательского интерфейса.
Расширение может работать в безопасном режиме. Саму опцию с произвольным кодом можно включать, например, на время отладки/тестирования.
Третье:
По поводу программных закладок полностью согласен. Полагаю, это можно решить в индивидуальном порядке.
Тогда у вас функциональность будет внутри 1С. А здесь то идея в том, чтобы можно было сделать какое-то приложение/сайт/портал, пользователи которого, не имеют доступа к 1С, но должны с ним взаимодействовать. Например портал студентов ВУЗа, портал сотрудников, портал чего-либо еще.
Можно и так и так. Вы можете написать код в 1С, оформить его в какой-нибудь функции, а дальше вызвать эту функцию из пхп. Результат будет сразу в удобном виде без необходимости парсинга.
Само расширение становится доступно только после установки конкретных ролей расширения. Если Вы будете работать от лица нового пользователя, то ему необходимо будет также прописать права и на основные объекты конфигурации, потому как у пустого пользователя даже на запуск 1С прав нет, а на доступ к БД тем более.
По дефолту у пользователя вообще нет никаких прав к расширению. Вы им не сможете воспользоваться, не добавив предварительно права.
В ролях расширения предусмотрена роль «Полные права», и отдельные роли на чтение данных, запись данных, удаленный вызов процедур и инжекцию кода. Их можно сочетать.
Это самое «штатное» API надо писать. Один раз это сделать не лень и интересно, но когда Вы это будете делать в десятый раз, Вы начнете замечать, что все эти API сильно похожи, отличаются только названия справочников, документов и запросы немного разные, а подход во всех конфигурациях 1С идентичный. По сути копипаста кода из одной конфигурации 1С в другую. И скорее всего, Вы захотите написать какой-то более универсальный механизм, чтобы один раз установил на любую конфигурацию и дальше пользуешься. А то, что он избыточный не беда, закрыл правами доступа и радуешься.
Само расширение является частью 1С и не может работать в обход системы ролей доступа 1С. Соответственно, если Ваш пользователь имеет доступ к таблицам только на чтение (или не имеет вообще доступа к ним), то даже с открытой инжекцией кода, он ничего удалить не сможет. А если и на чтение доступ убрать, то и прочитать не сможет.
Дело в том, что Ваш «контракт» тоже кто-то должен поддерживать в рабочем состоянии. Если 1С изменит какое-то поле, то в рабочем состоянии останутся только те контракты, которые разработаны самой фирмой 1С, потому что они отвечают за их корректную работу.
Но зачастую Вам нужно наладить интеграцию с конфигурацией 1С, которая является отраслевой и разрабатывается вообще третьими лицами (или самим заказчиком). И может так случиться, что никаких интерфейсов специально для Вас там никто не писал, а если и писал, то не те которые Вам нужны конкретно для Вашей задачи. В этом случае этот «контрактный интерфейс» Вам придется изобретать самому.
Кроме того, даже если крупная компания использует типовой программный продукт от самой 1С, то, скорее всего, он сильно доработан и содержит объекты, отражающие их отраслевую специфику. И интегрировать в свой «портал» они, вероятнее всего, захотят именно свою «отраслевую» функциональность, которая ни в каких типовых интерфейсах не отражена. В этом случае придется разрабатывать свой интерфейс и следить за его работоспособностью.
Как вариант, это можно сделать через Бром, отключив в нем все, что нарушает безопасность протокола, а также создав пользователя, который имеет доступы только к конкретным таблицам в 1С.
Подскажите, пожалуйста. Мне нужно подобрать сетевой контроллер доступа, к которому я бы мог подключаться из собственного программного обеспечения. В общих чертах, чтобы я мог со своего linux-сервера отправить команду контроллеру на открытие определенной двери. Желательно, чтобы интерфейс взаимодействия был HTTP (JSON/XML/SOAP и пр...) или хотя бы TCP/IP. Большинство предлагаемых контроллеров работают со своими тяжеловесными серверами, которые для моей задачи избыточны.
Можете ли что-то порекомендовать?
Если у кого-то получится его открыть, то и в паблик выкладывать его закрытым смысла нет. Я тогда просто выложу его открытым как есть.
Ведь если пользователь сайта, например, увидел на сайте цену на товар, взятую из 1С, то его вряд-ли можно назвать пользователем программы 1С.
Однако, если создать приложение, которое подменяет пользовательский интерфейс 1С, полагаю тут уже будет нарушение.
А остальные пользователи не нажимают эту кнопку и радуются тому, что у них есть возможность писать уязвимости.
Код пока закрыт только в расширении которое можно ставить в безопасном режиме, в клиентских библиотеках код НЕ защищен.
2. Само расширение в первую очередь предназначено для сервер-серверного взаимодействия между известными надежными узлами. Эту опцию Вы можете использовать для отладки и запретить на уровне ролей доступа на сервере 1С в рабочем проекте.
3. Накидать можно все что угодно, а можно уже накиданное взять.
Это все верно, если у Вас есть популярная публичная система, и Вам необходимо предоставить доступ неограниченному количеству разработчиков заранее неизвестных. Здесь я с Вами абсолютно согласен, предоставлять им гибкий доступ к системе неприемлемо.
Но чаще всего доступ к системе нужен не публичный, а для конкретного приложения, которое может разрабатываться той-же командой разработчиков для нужд той-же организации, которая использует 1С. Например, когда нужен внутренний портал с ограниченным доступом к данным из 1С, или какое-то специфическое приложение для внутренних сотрудников. В этом случае обе системы по сути являются частью единой более сложной системы и, скорее всего, расположены либо на одном сервере либо в изолированной корпоративной сети. В этом случае гибкий доступ к данным, может быть востребован, т.к. интегрируемому приложению Вы заранее доверяете.
Само описание пакетов не дает вам гарантии, что сервис работает корректно, т.к. нужно чтобы разработчики сервиса поддерживали его в актуальном состоянии, соответствующем имеющемуся описанию. В этом плане ничего не мешает создать интерфейсные методы в 1С на естественном для 1С языке и вызывать их удаленно через Бром (на низком уровне это будет тот же самый SOAP/XSD/XDTO, он описан в документации). Так же как и в первом случае эти методы придется актуализировать при обновлении системы. Разница только в том, что не придется программировать формирование XDTO-пакеты, т.к. упаковку и распаковку XDTO пакетов расширение делает автоматически.
Второе:
Вызов произвольного кода можно запретить (точнее не разрешать). Под клиентским приложением подразумевается серверная часть стороннего приложения, которому Вы доверяете (по отношению к 1С оно — клиент), возможно вы его сами и разрабатываете. Естественно, конечному клиенту не следует как либо взаимодействовать вообще с этим расширением напрямую из пользовательского интерфейса.
Расширение может работать в безопасном режиме. Саму опцию с произвольным кодом можно включать, например, на время отладки/тестирования.
Третье:
По поводу программных закладок полностью согласен. Полагаю, это можно решить в индивидуальном порядке.
В варианте «Использовать автоматически» он сам выбирает подходящую живую сессию.
В ролях расширения предусмотрена роль «Полные права», и отдельные роли на чтение данных, запись данных, удаленный вызов процедур и инжекцию кода. Их можно сочетать.
Само расширение является частью 1С и не может работать в обход системы ролей доступа 1С. Соответственно, если Ваш пользователь имеет доступ к таблицам только на чтение (или не имеет вообще доступа к ним), то даже с открытой инжекцией кода, он ничего удалить не сможет. А если и на чтение доступ убрать, то и прочитать не сможет.
Но зачастую Вам нужно наладить интеграцию с конфигурацией 1С, которая является отраслевой и разрабатывается вообще третьими лицами (или самим заказчиком). И может так случиться, что никаких интерфейсов специально для Вас там никто не писал, а если и писал, то не те которые Вам нужны конкретно для Вашей задачи. В этом случае этот «контрактный интерфейс» Вам придется изобретать самому.
Кроме того, даже если крупная компания использует типовой программный продукт от самой 1С, то, скорее всего, он сильно доработан и содержит объекты, отражающие их отраслевую специфику. И интегрировать в свой «портал» они, вероятнее всего, захотят именно свою «отраслевую» функциональность, которая ни в каких типовых интерфейсах не отражена. В этом случае придется разрабатывать свой интерфейс и следить за его работоспособностью.
Как вариант, это можно сделать через Бром, отключив в нем все, что нарушает безопасность протокола, а также создав пользователя, который имеет доступы только к конкретным таблицам в 1С.