Почему HTTP DELETE запрос в 1С к Mail.ru API возвращает ошибку 403 Forbidden, когда GET и POST работают?

← На главную

В рамках автоматизации задач по управлению пользователями почты через API Mail.ru мы часто сталкиваемся с необходимостью выполнять различные операции: создание, получение, изменение и удаление. Если операции создания (POST) и получения (GET) пользователей успешно отрабатывают, а при попытке удаления (DELETE) возникает ошибка 403 Forbidden, это может стать серьезным препятствием. Давайте разберемся в причинах такой ситуации и рассмотрим пошаговые методы устранения проблемы.

Проблема: 403 Forbidden при удалении пользователя через HTTP DELETE запрос в 1С

Автор описывает ситуацию, когда стандартные HTTP-запросы GET и POST успешно работают с API Mail.ru для создания и получения пользователей. Однако при попытке удалить пользователя методом DELETE сервер возвращает ошибку 403 Forbidden. При этом в теле ответа сервера присутствует сообщение о недостатке прав, что вызывает недоумение, так как используются административные учетные данные.

Рассмотрим исходный код 1С, который вызывает проблему:


Ид = ПолучитьДанные(); // Предполагается, что здесь получаем ID пользователя

Токен = ПолучитьТокенДляРаботыСMailRu(); // Функция для получения токена

Если Токен = Неопределено Тогда
    Возврат;
КонецЕсли;

Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type", "application/x-www-form-urlencoded");
Заголовки.Вставить("Authorization", "Bearer " + Токен);

Если ЗначениеЗаполнено(Ид) Тогда
    
    // Очищаем ID от невидимых символов и пробелов
    ИДФизЛица = СтрЗаменить(СтрЗаменить(Ид,Символы.НПП,"")," ",""); 
    
    HTTPЗапрос = Новый HTTPЗапрос("/api/v1/domains/1781427/users/" + ИДФизЛица, Заголовки);
                                 
    ТелоСтроки = ""; // Для DELETE запросов тело обычно пустое
    
    HTTPЗапрос.УстановитьТелоИзСтроки(ТелоСтроки);
    
    Попытка
        Соединение = Новый HTTPСоединение("biz.mail.ru",443,,,,,Новый ЗащищенноеСоединениеOpenSSL());
        Ответ = Соединение.Удалить(HTTPЗапрос); // Вызов метода DELETE
        Соединение = Неопределено;
    Исключение
        Соединение = Неопределено;
    КонецПопытки;
    
КонецЕсли;

В этом фрагменте кода мы видим, что для формирования запроса используются стандартные объекты 1С: HTTPЗапрос и HTTPСоединение. Заголовок Authorization передается с токеном типа Bearer, что является стандартной практикой для OAuth 2.0. Важно отметить, что тело запроса для DELETE устанавливается как пустая строка, что соответствует рекомендациям для этого метода.

Что означает ошибка 403 Forbidden? Разбираемся в статусах HTTP

Прежде чем углубляться в детали, давайте проясним смысл статуса 403 Forbidden. Эта ошибка указывает на то, что сервер понял ваш запрос, но отказывается его выполнить. Ключевое отличие от ошибки 401 Unauthorized заключается в том, что при 403 проблема не в отсутствии аутентификации (сервер вас узнал и ваш токен действителен), а в недостатке прав доступа к запрашиваемому ресурсу или для выполнения конкретного действия. Если 401 Unauthorized говорит "кто вы?", то 403 Forbidden говорит "вы – это вы, но вам сюда нельзя". В нашем случае, токен признан действительным (иначе GET/POST не работали бы), но с его помощью запрещено выполнять именно операцию удаления.

Таким образом, наша задача — выяснить, почему сервер отказывает в праве на удаление, несмотря на кажущиеся "админские" привилегии.

Проверка идентификатора пользователя (ИДФизЛица): скрытые ловушки

Одной из распространенных причин проблем при работе с API являются некорректные идентификаторы ресурсов. Хотя автор утверждает, что ИДФизЛица является корректным ID пользователя, мы настоятельно рекомендуем тщательно проверить его на наличие скрытых символов или лишних пробелов.

Обратите внимание на строку в коде, где происходит обработка идентификатора:

ИДФизЛица = СтрЗаменить(СтрЗаменить(Ид,Символы.НПП,"")," ","");

Функция СтрЗаменить используется для удаления неразрывных пробелов (Символы.НПП) и обычных пробелов. Несмотря на эту обработку, всегда существует риск, что в исходной переменной Ид могли остаться другие невидимые символы (например, управляющие символы), которые API Mail.ru воспринимает как часть ID, делая его невалидным. Если ID пользователя на самом деле содержит такие символы, сервер может посчитать запрос на удаление несуществующего или некорректно указанного ресурса как попытку неавторизованного доступа, что может привести к ошибке 403, если логика API предусматривает такую реакцию.

Для диагностики мы рекомендуем:

Вывести ИДФизЛица в лог или окно сообщений непосредственно перед формированием запроса, используя, например, Сообщить(ИДФизЛица), чтобы убедиться в его точном содержимом, включая возможные непечатаемые символы. Для более точного анализа можно вывести его длину Сообщить(СтрДлина(ИДФизЛица)) и отдельные символы.
Сравнить полученный ID с ID, который вы используете для успешных GET-запросов (если он передается в URL), или с эталонным ID из документации/интерфейса Mail.ru. Убедитесь в их абсолютном совпадении.
Убедиться, что ID относится к существующему пользователю и что этот пользователь находится в том же домене, что и 1781427, указанный в URL запроса. Иногда ошибка 403 может возникать, если вы пытаетесь удалить пользователя из другого домена, на который ваш токен не имеет прав, даже если сам токен валиден.

Гранулярные разрешения токена (Scopes): главная причина ошибки 403

Наиболее вероятная причина ошибки 403, особенно когда GET и POST работают, кроется в областях действия (scopes) выданного токена. Многие API, включая те, что используют стандарт OAuth 2.0, предоставляют разные уровни доступа для различных операций. Получение токена происходит в несколько этапов, и на этапе запроса токена клиентское приложение должно указать, какие именно действия оно собирается выполнять.

Представим, что ваш "админский" токен, который позволяет создавать и изменять пользователей, имеет только права user.write или user.manage. Однако для операции удаления может требоваться отдельное, более чувствительное разрешение, например, user.delete или admin.delete. Даже если вы считаете, что у вас есть "админские" права, API может интерпретировать их в контексте специфических разрешений токена, которые были явно запрошены и предоставлены при его выдаче.

Проанализируем ситуацию:

Токен действителен: Если бы токен был недействителен или просрочен, вы получили бы ошибку 401 Unauthorized. Тот факт, что GET и POST работают, подтверждает валидность токена как средства аутентификации.
Ошибка 403 с сообщением "нет прав" в теле ответа: Это прямо указывает на то, что сервер понимает, кто вы (через токен), но не позволяет вам выполнить конкретную операцию (DELETE) из-за недостаточных разрешений, закрепленных за этим токеном. Это классический случай для проблем с scopes.

Что мы можем сделать для диагностики и решения этой ключевой проблемы:

Изучите документацию Mail.ru API: Внимательно перечитайте раздел, касающийся получения токена и операций с пользователями, особенно в части удаления. Ищите информацию о требуемых scopes (областях действия) для метода DELETE. Вероятно, там будет указано, какой именно scope необходим для удаления пользователей. Например, для создания пользователей может быть достаточно users.write, а для удаления — users.delete.
Проверьте, какие scopes были запрошены при получении вашего токена. Обычно при запросе токена вы указываете, какие разрешения вам нужны (например, в параметре scope=user.read+user.write+user.delete). Убедитесь, что разрешение на удаление было запрошено и успешно предоставлено. Если при получении токена вы не указывали явно scope для удаления, токен может его не иметь.
Попробуйте получить новый токен, явно запросив все необходимые разрешения, включая delete (если это предусмотрено API), и используйте его для DELETE-запроса. Это часто является самым прямым путем к решению проблемы 403, связанной с разрешениями.

Способы передачи токена и их влияние

В большинстве случаев токен авторизации передается в заголовке Authorization: Bearer <токен>, как это сделано в нашем примере. Это наиболее безопасный и рекомендуемый способ, так как токен не попадает в логи веб-сервера или в кэш браузера.

Однако, в некоторых API также поддерживается передача токена в строке запроса как параметр access_token. Автор уже пробовал этот вариант, и он не сработал. Тем не менее, для полноты картины, мы можем рассмотреть этот вариант как альтернативный, если возникают проблемы с заголовками, хотя для DELETE он менее предпочтителен.

Пример передачи токена в строке запроса:


// ...
Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type", "application/x-www-form-urlencoded");
// Заголовок Authorization в этом случае может быть опущен или сделан пустым,
// если API допускает только один способ передачи токена.

HTTPЗапрос = Новый HTTPЗапрос("/api/v1/domains/1781427/users/" + ИДФизЛица + "?access_token=" + Токен, Заголовки);
// ...

Если оба метода передачи токена приводят к 403, это еще раз подтверждает, что проблема не в способе передачи, а в самом содержании или правах, закрепленных за токеном, что возвращает нас к пункту о гранулярных разрешениях.

Особенности HTTP метода DELETE

Метод HTTP DELETE предназначен для удаления указанного ресурса. Важно помнить о нескольких его особенностях, которые могут влиять на обработку запроса сервером:

Тело запроса: Как правило, DELETE-запросы не должны содержать тела. Вся необходимая информация для идентификации ресурса (в нашем случае ИДФизЛица) передается в URL. Автор в своем коде правильно устанавливает пустое тело: ТелоСтроки = ""; HTTPЗапрос.УстановитьТелоИзСтроки(ТелоСтроки); Некоторые промежуточные серверы или WAF могут блокировать DELETE-запросы с непустым телом из соображений безопасности.
Идемпотентность: DELETE является идемпотентным методом. Это означает, что многократное выполнение одного и того же запроса на удаление одного и того же ресурса даст тот же результат, что и однократное выполнение (ресурс будет удален один раз, а последующие запросы к уже удаленному ресурсу могут вернуть 404 Not Found или 410 Gone). Это свойство важно для надежности API.
Ожидаемые коды ответа:
- 204 No Content: Наиболее частый ответ при успешном удалении, если сервер не возвращает никакого тела ответа.
- 200 OK: Если в теле ответа содержится подтверждение удаления или информация об удаленном ресурсе.
- 404 Not Found: Если ресурс, который вы пытаетесь удалить, не существует.
- 410 Gone: Ресурс был удален и больше не доступен, что указывает на то, что он был удален перманентно.

Дополнительные шаги для диагностики и устранения

Если после проверки всех вышеуказанных пунктов проблема сохраняется, мы можем предпринять следующие дополнительные действия:

Детальное изучение документации Mail.ru API: Вернитесь к документации и внимательно проверьте все детали, касающиеся удаления пользователей. Возможно, существуют специфические требования к заголовкам, параметрам или условиям, которые отличаются от GET/POST. Некоторые API могут требовать специфический заголовок X-CSRF-Token для операций, изменяющих данные.
Анализ полного тела ответа сервера: Ошибка 403 иногда сопровождается более подробным сообщением в теле ответа (например, в формате JSON), которое может конкретно указать на причину отказа (например, {"error": "insufficient_scope", "description": "The request requires a 'users.delete' scope."}). Убедитесь, что вы полностью считываете и анализируете содержимое переменной Ответ после выполнения запроса. Это может дать ценную информацию. В 1С, для чтения тела ответа, можно использовать методы ПолучитьТелоКакСтроку() или ПолучитьТелоКакДвоичныеДанные() объекта HTTPОтвет.
Проверка ограничений на стороне сервера или WAF (Web Application Firewall): В редких случаях, даже при наличии всех прав, запросы DELETE к критически важным ресурсам могут блокироваться фаерволами или другими защитными механизмами сервера как мера безопасности. Это менее вероятно, если другие операции работают, но стоит иметь в виду. Если вы работаете из корпоративной сети, проверьте, нет ли на вашем периметре сетевых устройств, которые могут фильтровать HTTP-запросы.
Использование инструментария для отладки HTTP-запросов: Используйте такие инструменты, как Postman, Insomnia или аналогичные, чтобы сформировать DELETE запрос вручную с теми же заголовками, токеном и URL. Это позволит изолировать проблему: если запрос работает в Postman, значит, проблема в реализации на стороне 1С (например, некорректная кодировка, ошибки в формировании URL); если не работает и в Postman, значит, проблема на стороне API или токена, что позволит исключить 1С из списка подозреваемых.

В заключение, ошибка 403 Forbidden при HTTP DELETE запросе в 1С чаще всего указывает на проблему с недостаточными гранулярными правами (scopes) у токена авторизации, который используется для запроса. Тщательная проверка идентификатора пользователя и детальное изучение документации API в части требований к правам доступа и формату запроса помогут успешно решить эту задачу.