При интеграции сторонних веб-ресурсов или мобильных приложений с базой данных 1С программисты часто используют стандартный REST-интерфейс OData. Это мощный встроенный инструмент, который позволяет получать и изменять данные 1С с помощью стандартных HTTP-запросов. Однако на начальном этапе разработчики часто сталкиваются с проблемой: при попытке вызвать ссылку вида http://192.168.70.2/CreditFinance/odata/standard.odata/Catalog_ФизическиеЛица в браузере или коде приложения система запрашивает имя пользователя и пароль, а прямая передача учетных данных в строке запроса не работает.
В этой статье мы подробно разберем, как правильно реализовать авторизацию при работе с OData, почему стандартные браузерные методы могут блокировать запросы, и как настроить безопасное соединение между вашим сайтом и базой 1С. В случаях, когда использование стандартного API невозможно, задачи интеграции решаются через роботизацию действий пользователя без использования программного интерфейса.
Исторически в стандартах URI существовала возможность передавать учетные данные непосредственно в адресе ссылки, например: http://admin:my_password@192.168.70.2/.... Однако современные веб-браузеры в целях безопасности полностью заблокировали или существенно ограничили этот механизм (согласно рекомендациям стандарта RFC 3986).
Такой подход защищает пользователей от фишинговых атак, когда злоумышленники маскируют вредоносные ссылки. Если вы попытаетесь выполнить подобный запрос из клиентского JavaScript-кода в браузере, запрос гарантированно завершится ошибкой авторизации или будет заблокирован на этапе отправки. Тем не менее, этот формат все еще может работать во внешних серверных утилитах (например, при отправке запросов через cURL), но для полноценной веб-разработки использовать его крайне не рекомендуется.
Для успешного прохождения проверки подлинности в 1С OData используется стандартный метод Basic Authentication. При этом методе логин и пароль пользователя передаются не в URL-адресе, а внутри служебных HTTP-заголовков запроса.
Давайте разберем алгоритм формирования такого заголовка по шагам:
admin с паролем 12345 мы получим строку: admin:12345.admin:12345 после кодирования превратится в хеш-последовательность YWRtaW46MTIzNDU=.Authorization, а в качестве его значения передается слово Basic, после которого через пробел указывается сгенерированный Base64-код: Authorization: Basic YWRtaW46MTIzNDU=.Когда веб-сервер (IIS или Apache), на котором опубликована база 1С, получает такой запрос, он декодирует заголовок, сопоставляет учетные данные со списком пользователей 1С и, в случае успеха, возвращает запрошенные данные без появления диалоговых окон авторизации. Для проверки работы заголовков и параметров защищенной авторизации можно использовать обработку для тестирования HTTP-сервисов.
Рассмотрим практический пример отправки запроса к справочнику физических лиц с использованием современного Fetch API в JavaScript.
Важное примечание: стандартная функция btoa() в JavaScript отлично работает с латинскими символами, но может вызывать ошибки, если в имени пользователя или пароле 1С содержатся кириллические буквы (что часто бывает в русскоязычных базах данных). Чтобы избежать этой проблемы, мы предварительно выполним правильное кодирование строки в UTF-8.
Посмотрим на пример кода:
// Функция для безопасного кодирования строки с кириллицей в Base64
function safeBtoa(str) {
return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, function(match, p1) {
return String.fromCharCode('0x' + p1);
}));
}
const username = 'СлужебныйПользователь';
const password = 'СложныйПароль123';
const url = 'http://192.168.70.2/CreditFinance/odata/standard.odata/Catalog_ФизическиеЛица?$format=json';
const headers = new Headers();
// Формируем заголовок Basic-авторизации
headers.set('Authorization', 'Basic ' + safeBtoa(username + ":" + password));
fetch(url, {
method: 'GET',
headers: headers
})
.then(response => {
if (!response.ok) {
throw new Error('Ошибка сети или авторизации: ' + response.statusText);
}
return response.json();
})
.then(data => {
console.log('Данные из 1С успешно получены:', data);
})
.catch(error => {
console.error('Произошла ошибка при выполнении запроса:', error);
});
При отправке запросов напрямую из браузера (из скриптов на вашем сайте) вы почти наверняка столкнетесь с тем, что браузер заблокирует выполнение запроса из-за политики безопасности CORS. Браузер запрещает скриптам с одного домена (например, https://mysite.ru) запрашивать данные с другого адреса (например, http://192.168.70.2), если удаленный сервер явно не разрешил такое взаимодействие.
Выясним, какими способами можно решить эту проблему.
Вместо того чтобы отправлять запросы к 1С напрямую из браузера пользователя, запросы выполняет серверная часть вашего сайта (написанная на PHP, Python, Node.js или любом другом серверном языке). Клиентский скрипт делает запрос к вашему же серверу, а сервер в фоновом режиме обращается к 1С и возвращает результат клиенту. Для контроля качества передаваемой информации можно автоматически сверять бухгалтерские и налоговые проводки между базами после завершения обмена.
У этого подхода есть важнейшие преимущества:
Проанализируем пример простой реализации такого прокси-скрипта на языке PHP:
<?php
// proxy.php - скрипт на сервере вашего сайта
$username = 'СлужебныйПользователь';
$password = 'СложныйПароль123';
$url = 'http://192.168.70.2/CreditFinance/odata/standard.odata/Catalog_ФизическиеЛица?$format=json';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// Включаем базовую авторизацию в cURL
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($ch, CURLOPT_USERPWD, "$username:$password");
$response = curl_exec($ch);
$http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if ($http_code !== 200) {
http_response_code($http_code);
echo json_encode(["error" => "Ошибка запроса к 1С", "details" => curl_error($ch)]);
} else {
header('Content-Type: application/json; charset=utf-8');
echo $response;
}
curl_close($ch);
?>
Если архитектура приложения требует отправки запросов именно с клиентской стороны, необходимо настроить веб-сервер, на котором опубликована база 1С (IIS или Apache), чтобы он отдавал разрешающие заголовки в ответ на запросы вашего сайта.
При использовании веб-сервера Apache в конфигурационный файл httpd.conf или в файл .htaccess в каталоге публикации базы необходимо добавить следующие правила:
Header set Access-Control-Allow-Origin "https://mysite.ru"
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization"
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
# Обработка предзапроса OPTIONS (preflight request), который браузер шлет перед основным запросом
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
При использовании веб-сервера IIS аналогичные настройки производятся через установку модуля "IIS CORS Module" и корректировку файла конфигурации web.config в папке публикации информационной базы.
Чтобы авторизация проходила успешно и вы могли работать со справочниками, необходимо выполнить правильную настройку внутри самой базы данных 1С:
odata_user.УдаленныйДоступOData (в типовых конфигурациях).Показывать в списке выбора. Это повысит безопасность системы и не позволит обычным пользователям видеть служебную учетную запись при запуске программы.ФизическиеЛица), к которым вы хотите разрешить удаленный доступ.По умолчанию REST-интерфейс 1С может отдавать информацию в формате XML (Atom/XML). Этот формат неудобен для разбора в веб-сценариях и увеличивает объем передаваемого трафика.
Чтобы сервер 1С отдавал данные в удобном формате JSON, всегда добавляйте в конец строки запроса специальный параметр: ?$format=json. Для визуального конструирования таких URL-параметров подойдёт генератор запросов к OData-интерфейсу 1С.
Также для оптимизации работы сети полезно использовать следующие параметры:
$select — позволяет указать конкретные реквизиты, которые нужно вернуть. Например: .../Catalog_ФизическиеЛица?$select=Description,Code&$format=json. Это избавит вас от получения тяжелых и ненужных полей.$filter — используется для фильтрации данных на стороне сервера 1С. Например, выборка физлиц по определенному условию.Мы подробно разобрали, как устроена базовая авторизация в REST OData 1С, изучили механизм составления заголовков авторизации, рассмотрели готовые примеры кода для интеграции и научились обходить ограничения безопасности. Используйте проксирование на стороне бэкенда для защиты конфиденциальных данных и всегда ограничивайте права служебных пользователей 1С до минимально необходимых. Для настройки постоянной синхронизации можно автоматизировать регулярный обмен данными между базами 1С по заданному расписанию.