Получить публикацию Office 365 calendar JSON без шага OAuth2?

Question

Edit:

Изначально вопрос был как получить Office365 календарь в формате JSON без аутентификации; но я имел в виду, как получить календарь Office365 в JSON, не требуя шага OAuth2 (так, например, на стороне сервера другие методы проверки подлинности приемлемы для извлечения данных календаря).

Проблема:

Я хотел бы использовать Office 365 REST API для доступа к этому опубликованному календарю (т.е. операции «чтение» только с календарем публикуется), так что я могу «стиль» календарю, как я предпочитаю. Итак, я ищу публичный подход API к использованию одного из моих календарей. Примеры кода для API REST Office 365, которые я нашел, используют OAuth для аутентификации клиента. Это кажется излишним.

У меня есть некоторые возможные решения, поэтому любые предложения по наилучшему подходу приветствуются.

фона:

У меня есть опубликованный календарь в Office365, который дает мне корм:

http://outlook.office365.com/owa/calendar/USER@DOMAIN/CALENDAR_NAME/calendar.ics

и URL:

http://outlook.office365.com/owa/calendar/USER@DOMAIN/CALENDAR_NAME/calendar.html

Как может Я делаю то, что делает «calendar.html», чтобы я мог вытеснять y календарь, как я хотел бы, чтобы он отображался (вместо IFraming, который предоставляет Office365)?

Пример:

Ниже приведен пример URL с помощью REST API:

https://outlook.office365.com/api/v1.0/users/USER@DOMAIN/calendars

Браузер приведет базовую диалог аутентификации, поэтому он выглядит как OAuth не только (одно возможное решение, запрос может быть проксирован с локального сервера, который вызывает REST API, используя базовую аутентификацию).

Вопросы:

• Одна проблема может быть, что функция календаря «издательство» предназначена для ограниченного объема данных (например, 1 год до или в будущем на самый), который является то, что Я предполагаю, что файл iCalendar (* .ics) будет содержать для любого запроса.

• Использование API REST при проверке подлинности предполагает, что ограничение диапазона дат не существует (поскольку запрос с помощью REST API можно запросить в календаре, я предполагаю, что вы можете запросить более назад, чем год).

Возможные решения:

• Proxy запрос с другого сервера, делая вызовы API REST, используя базовую аутентификацию. Кэширование также может потребоваться, так как кажется, что время ответа может быть медленным. Календарь может быть либо JavaScript, который использует локальную конечную точку, либо HTML-контент, созданный на сервере.

• Похоже Office365 AuthenticationContext.AcquireTokenAsync() примет ClientCredential (идентификатор клиента и секрет) или также UserCredential (простое имя пользователя и пароль). Итак, я думаю, что могу запустить локальную прокси-службу, которая использует библиотеку Office365, вручную передавая учетные данные функции, которая приобретает токен. (Я все еще нужно, чтобы проверить это, чтобы убедиться, что функция действительно будет работать таким образом.)

• Просто IFrame страница «calendar.html» обеспечивают Бюро 365. (предотвращено домен Cross, если это не на один из Microsoft принимала решения «что-то перемычками»).

• При использовании (* Анонсы .ics) питающие, то можно было бы нужна функция преобразования для формата JSON в Анонсы ( https://github.com/kewisch/ical.js), то JavaScript или библиотека календарей может использоваться для создания пользовательского календаря. (Это не очень удобно для просмотра событий календаря в течение года без обналичивания и предоставления механизма запроса, за исключением отображения одного месяца назад и вперед. Таким образом, какой-то тип ics2json для использования на FullCalendar может работать только для пары месяцы истории календаря.)

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

Answer 1

Для работы API Office 365 требуется Oauth2. Если вы используете Visual Studio для разработки своего приложения, инструменты O365 для промежуточного программного обеспечения Visual Studio + OWIN будут обрабатывать много работы oauth для вас.

Если oauth абсолютно не вариант, я бы вместо этого использовал API EWS, который может использовать базовую аутентификацию (дополнительная информация об этом here на MSDN).