2016-09-28 3 views
0

Я создал проект webhook с API-интерфейсом Microsoft Graph для контроля входящих сообщений Office 365.Автоматическое обновление для подписки API графиков Microsoft

Я сделал метод UpdateSubscription действий, который обновляет его в течение 3 дней только в соответствии с документацией обеспечить на https://graph.microsoft.io/en-us/docs/api-reference/v1.0/resources/subscription

Ниже приведен фрагмент кода, как I'am облегчения запроса HTTP, чтобы обновить подписку на

 AuthenticationResult authResult = await AuthHelper.GetAccessTokenAsync(); 

     HttpClient client = new HttpClient(); 
     client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken); 
     client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); 

     // Build the request. 
     string subscriptionsEndpoint = "https://graph.microsoft.com/v1.0/subscriptions/"+id; 
     var method = new HttpMethod("PATCH"); 

     HttpRequestMessage request = new HttpRequestMessage(method, subscriptionsEndpoint); 

     //get the current time 

     var subscription = new Subscription 
     { 
      //Id = id, 
      ExpirationDateTime = DateTime.UtcNow + new TimeSpan(0, 0, 4230, 0) 
     }; 

Есть ли способ автоматического обновления без нажатия кнопки «обновить»?

, так как для заголовков авторизации требуется AuthResult.accessToken, которые потребуют от пользователя входа в учетную запись Office365.

Пожалуйста, советы

+0

Я смог обновить подписку пользователя, извлекая «RefreshToken» из HttpRuntimeCache, который используется для получения токена доступа, используя следующий метод GetAccessTokenFromRefreshTokenAsync. Однако при перезагрузке приложения кеш не будет иметь «RefreshToken». Безопасно ли хранить это в базе данных –

ответ

1

Опция доступна для вас служба или демон подход (https://graph.microsoft.io/en-us/docs/authorization/app_only). Вместо аутентификации с помощью зарегистрированного пользователя вы можете продлить подписку на уровне приложения, используя токен-носитель, который, в свою очередь, генерируется CLIENT_SECRET от Azure AD.

Я не думаю, что хранить токены в базе данных - это правильный подход. Я понимаю, что токены безопасности никогда не подходят для базы данных.

На самом деле, я не совсем понимаю необходимость входа пользователя в систему здесь, если в программе нет частей, о которых вы не упомянули. Служба, подобная той, которую я упоминал, может отслеживать почтовый ящик без пользователя, или если программа требует, чтобы пользователь был там, действительно не проблема с потерянными учетными данными.

0

enter image description here Вы можете использовать этот подход для получения accesstoken из лазурного, используя пароль grant_type. PLease найти снимок экрана ниже.

Смежные вопросы