#microsoft-graph-api #microsoft-graph-security
#microsoft-graph-api #microsoft-graph-безопасность
Вопрос:
Я начинаю использовать API оценки угроз Microsoft Graph для сообщения о URL-адресе фишингового веб-сайта.
(Ссылка: https://learn.microsoft.com/en-us/graph/api/informationprotection-post-threatassessmentrequests?view=graph-rest-1.0amp;tabs=http)
Мой вариант использования — автоматическая отчетность и отчетность вручную с помощью команды Slack. Но регулирование очень строгое, поэтому я немедленно получаю ответ «429».
"code": "ActivityLimitReached",
"message": "The client application has been throttled for reaching an activity limit. The request may be repeated after a delay, the length of which may be specified in a 'Retry-After' header.",
Кто-нибудь знает обходной путь для регулирования?
Насколько я подтвердил, регулирование 1 request per 15 minutes (Limit per resource) установлено по умолчанию.
( 150 requests per 15 minutes (Limit per tenant) хотя)
Ссылка: https://learn.microsoft.com/en-us/graph/throttling#information-protection
Ответ №1:
Я бы попробовал следующую наилучшую практику, чтобы избежать / справиться с регулированием.
При реализации обработки ошибок используйте код ошибки HTTP 429 для обнаружения регулирования. Неудачный ответ включает заголовок ответа «Повторить попытку после». Резервное копирование запросов с использованием задержки повторной попытки — это самый быстрый способ восстановления после регулирования, поскольку Microsoft Graph продолжает регистрировать использование ресурсов во время регулирования клиента.
- Подождите количество секунд, указанное в заголовке Повторной попытки.
- Повторите запрос.
- Если запрос снова завершается ошибкой с кодом ошибки 429, вы по-прежнему управляетесь. Продолжайте использовать рекомендуемую задержку повторной попытки и повторяйте запрос до тех пор, пока он не завершится успешно.
Руководство по регулированию уже предоставлено командой Microsoft Graph, и оно простое. Пожалуйста, ознакомьтесь с этим документом, найдите рекомендации по предотвращению регулирования, управлению регулированием и т. Д. И подумайте о регулировании / пакетировании, чтобы увидеть, подходит ли оно вашему сценарию (чтобы вы могли оптимизировать вызовы).
Если заголовок retry-after не существует, тогда это будет сложно — вот способ обработки регулирования, если не предусмотрен какой-либо альтернативный способ. Если вы все еще верите, что Microsoft реализует эту функцию, рассмотрите возможность создания нового голоса пользователя.
Обновление: @rung создал новый пользовательский голос для этого.
Комментарии:
1. Спасибо, к сожалению, вы не можете получить заголовок повторной попытки из ошибки 429 API для оценки угроз, а само регулирование слишком строго относится к немедленному сообщению о фишинге. Итак, я хотел бы знать обходной путь. (если в api нет обходного пути, я мог бы создать достаточное количество пользователей в том же клиенте, чтобы сообщать только о фишинге.)
2. Если заголовок retry-after не существует, тогда это будет сложно — вот способ обработки регулирования, если не предусмотрен какой-либо альтернативный способ. Если вы по-прежнему считаете, что Microsoft реализует эту функцию, рассмотрите возможность создания нового голоса пользователя на — microsoftgraph.uservoice.com/forums /…
3. Большое вам спасибо. имеет смысл, я спрошу об этом сейчас.
4. Прохладный. Я также обновил приведенный выше ответ. Как только вы сможете создать голос пользователя, не стесняйтесь поделиться им здесь. Так что это может быть полезно и другим.
5. Спасибо за вашу навигацию. Я добавил голос пользователя microsoftgraph.uservoice.com/forums /…
Ответ №2:
Я работаю над аналогичным вариантом использования. Я планирую отправить идентификатор / URL / файл Msg в Microsoft для оценки фишинга с использованием API. Я застрял с ошибкой, которая показывает » «код»: «Несанкционированный»,
"message": "Required authentication information is either missing or not valid for the resource.",
«
Я был бы очень признателен за вашу помощь!