Каким способом соединения с БД 1С можно у принимающей стороны видеть, кто инициатор соединения?
Есть БД1, у нее, допустим, есть http-сервис. Есть БД2, из нее посылается запрос по этому сервису. БД1 принимает запрос, и требуется видеть, что запрос послан именно из БД2, а не сторонней программой, системой.
ВАЖНО, данные отправителя нужно чтобы нельзя было подделать. Т.е. добавить заголовки вроде "источник"-"БД2" и отправить запрос откуда угодно - не подойдет.
Скорее всего, средствами 1С сделать такое возможности нет. Но может есть какой хитрый способ, вроде COM-соединения, ODATA или еще как.
Главная цель - создать закрытое соединение между базами, чтобы в базу с данными нельзя было подсоединиться из других баз программисту.
БД1 - закрыта для широкого круга разработчиков, БД2 - доступна для широкого круга.
ВАЖНО, данные отправителя нужно чтобы нельзя было подделать. Т.е. добавить заголовки вроде "источник"-"БД2" и отправить запрос откуда угодно - не подойдет.
Скорее всего, средствами 1С сделать такое возможности нет. Но может есть какой хитрый способ, вроде COM-соединения, ODATA или еще как.
Главная цель - создать закрытое соединение между базами, чтобы в базу с данными нельзя было подсоединиться из других баз программисту.
БД1 - закрыта для широкого круга разработчиков, БД2 - доступна для широкого круга.
Найденные решения
(9) Придумал вот что, прошу развить:
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.
Вот четвертый пункт интересный, я пока не знаю как передавать данные между сеансами, не сохраняя их в файлы и БД
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.
Вот четвертый пункт интересный, я пока не знаю как передавать данные между сеансами, не сохраняя их в файлы и БД
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Вероятно что-то типа такого, через сертификаты.
Для БД2 поднять отдельную службу сервера, с отдельным пользователем, ему поставить сертификат. Обращаться к сервису только из серверного контекста.
Соответственно, не работает, если будут права создать новую базу на этом же сервере 1С.
UPD: сертификат программно тоже можно получить при наличии полных прав, так что, вероятно, и это не подойдет.
Для БД2 поднять отдельную службу сервера, с отдельным пользователем, ему поставить сертификат. Обращаться к сервису только из серверного контекста.
Соответственно, не работает, если будут права создать новую базу на этом же сервере 1С.
UPD: сертификат программно тоже можно получить при наличии полных прав, так что, вероятно, и это не подойдет.
(9) Придумал вот что, прошу развить:
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.
Вот четвертый пункт интересный, я пока не знаю как передавать данные между сеансами, не сохраняя их в файлы и БД
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.
Вот четвертый пункт интересный, я пока не знаю как передавать данные между сеансами, не сохраняя их в файлы и БД
(11) Такая схема похожа на асинхронный обмен. Т.е. после 1 шага БД 2 должна закончить соединение и просто периодически проверять некое хранилище на наличие новых записей(тем более в 8.3.25 Пауза() появилась:)).
1. Сделали вызов из БД2 в БД1, в ответ получились некий ID, завершили соединение.
2. БД1 подготовила данные, передала их в БД2, в БД2 в некий регистр сложили данные с этим же ID.
3. БД2 периодически проверяет наличие записи в регистре с нужным ID, при появлении идет дальше по алгоритму.
1. Сделали вызов из БД2 в БД1, в ответ получились некий ID, завершили соединение.
2. БД1 подготовила данные, передала их в БД2, в БД2 в некий регистр сложили данные с этим же ID.
3. БД2 периодически проверяет наличие записи в регистре с нужным ID, при появлении идет дальше по алгоритму.
(15)
если совсем серьезно подходить...
то далее упретесь в теорию чисел и методы высшей математики.
там идея что есть два простых! числа (знаков ~250) A и Б и их произведение. данное произведение однозначно раскладывается на А и Б. в общем небольшое отклонение на Q от произведения.
приводит к тому что найти обратное решение - задача решаема, но время трудозатрат более 100 лет.
т.е. есть А*Б + Q = С - посылаем С. надо найти А Б. - Q ключ который позволяет быстро найти их - он зашифрован и никуда не передается.
если совсем серьезно подходить...
то далее упретесь в теорию чисел и методы высшей математики.
там идея что есть два простых! числа (знаков ~250) A и Б и их произведение. данное произведение однозначно раскладывается на А и Б. в общем небольшое отклонение на Q от произведения.
приводит к тому что найти обратное решение - задача решаема, но время трудозатрат более 100 лет.
т.е. есть А*Б + Q = С - посылаем С. надо найти А Б. - Q ключ который позволяет быстро найти их - он зашифрован и никуда не передается.
По моему данная коллизия не решаема т.к. априори подразумевается не надёжность источника данных.
Мне видится решение - В первую очередь необходимо уверенность в безопасности источника, если мы уверены что безопасность не поколебима, то делаем DLL в нее зашиваем алгоритм генерации Хэш суммы на основании например имени базы данных, даты пакета, номера пакета.
Далее в приемники аналогичная DLL генерирует хэш суммы на основании принятого пакета и сверяет ее.
Мне видится решение - В первую очередь необходимо уверенность в безопасности источника, если мы уверены что безопасность не поколебима, то делаем DLL в нее зашиваем алгоритм генерации Хэш суммы на основании например имени базы данных, даты пакета, номера пакета.
Далее в приемники аналогичная DLL генерирует хэш суммы на основании принятого пакета и сверяет ее.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот