Сценарий Powershell, использующий почтовый API Office 365, больше не работает

У нас есть сценарий powershell, который будет захватывать вложения из общего почтового ящика в Outlook Office 365. Теперь, когда почтовый API v1 больше не поддерживает базовую аутентификацию, этот скрипт перестал работать прошлой ночью, и теперь мне нужно использовать oAuth?

Я буду честен и понятия не имею, как сделать этот переключатель, и несколько раз читал документацию, но я думаю, что сейчас я еще больше потерялся. Из всего, что я продолжаю читать, говорится, что мне нужно создать приложение сейчас, зарегистрировать приложение, а затем сгенерировать носитель или токен доступа через конечную точку, которая попадает в это приложение? Это правда, мне действительно нужно все это делать?

Нет ли места, где я могу просто сгенерировать токен API с учетной записью Microsoft?

по сути, это сценарий, который мы использовали: https://gallery.technet.microsoft.com/office/O365-Email-Attachments-to-6a45e84c


powershell outlook outlook-api
person Govna    schedule 09.01.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Мы находимся в такой же ситуации. Вероятно, из-за закрытия REST API Outlook.office365.com и API Graph, который теперь используется по умолчанию: Как получить содержимое itemAttachment через API Microsoft Graph https://docs.microsoft.com/nl-be/graph/api/attachment-get?view=graph-rest-1.0#request-2

Теперь я собрал скрипт, чтобы сделать это правильно, и он работает. Но (1) он требует ввода пароля с графическим интерфейсом каждый раз, когда запускается скрипт (например, после сбоя питания), и после входа в систему (2) срок действия токена доступа продолжает истекать...

Invoke-RestMethod : {
  "error": {
    "code": "InvalidAuthenticationToken",
    "message": "Access token has expired.",
    "innerError": {
      "request-id": "1c991403-ab46-4aec-a7a1-316dbdfb4eb8",
      "date": "2019-01-16T12:29:50"
    }
  }
}

Теперь, когда вы попадаете в документацию и начинаете читать о таких вещах, как обновление токена и тому подобное... Это просто безумие! https://docs.microsoft.com/nl-be/graph/auth-v2-user

Я разработал интерфейс API для MailChimp, который я выполнил менее чем за ОДИН час... (1) сгенерировать ключ API в MailChimp, (2) использовать этот ключ API в своих сценариях и, при необходимости, (3) отозвать ключ в MailChimp в случае ЧП (СДЕЛАНО).

Этот токен M$ BS действительно сногсшибателен. Насколько я понимаю, вам нужно либо использовать инструмент администратора PowerShell, чтобы изменить токены на 90-дневную продолжительность по умолчанию (но, насколько я понимаю, на уровне сервера, а не на уровне приложения?), либо автоматически обновлять токен доступа каждые 5 минут в вашем скрипте.

Вот почему я сейчас рассматриваю возможность использования PSMSGraph, который, очевидно, сделает все это за вас: https://psmsgraph.readthedocs.io/en/latest/

Если вы хотите, чтобы он работал правильно, прежде чем я это сделаю, поделитесь своим кодом. Поскольку мое текущее решение требует ручного ввода пароля (кстати, я не понимаю, как я могу сделать это безголовым) и перестает работать через час из-за истечения срока действия токена.

Я уверен, что есть веская причина (безопасность) использовать этот способ токена доступа, но если способ MailChimp для создания токенов жизни ПРОСТО РАБОТАЕТ... Тогда я не понимаю, почему эта сложность токена доступа с Microsoft Graph API нужен в первую очередь.

person helonaut    schedule 16.01.2019
comment
Спасибо за ответ, мы все еще ищем другие варианты, так как мы обнаружили, что это (API Graph) немного громоздко для нас, учитывая, что это выходит за рамки того, что мы обычно делаем. Вместо этого изменения мы просто разработали почтовую программу, использующую настройки imap и pop3 для получения любых непрочитанных вложений из почтового ящика. На самом деле он использует базовую аутентификацию в том смысле, что у нас есть хешированные, но введенные значения un и pw. Токены не требуются, но я не думаю, что это решение работает для большинства людей. Нам повезло, что у кого-то есть эта старая программа на машине, и мы модифицировали ее для наших нужд. - person Govna; 23.01.2019
comment
Спасибо за отзыв Говна. Вы абсолютно правы в том, что график API громоздкий, а не просто немного. Я разработал решения для многих API, и это было вопросом генерации ключа и использования этого ключа в вызовах API к этой службе. Ни больше ни меньше. Маркер доступа, созданный на платформе AD Azure, должен иметь только индивидуальную переменную времени жизни, которую может настраивать любой администратор с помощью раскрывающегося списка рядом с ключом. Может быть, они могли бы добавить поле, как будто я знаю, что делаю, я доверяю этому пользователю/программе. Готово. - person helonaut; 23.01.2019