Я обновляю дополнение Excel, которое я сделал 2-3 года назад с помощью С#. Цель состоит в том, чтобы получить некоторые файлы, хранящиеся на сайте SharePoint, скопировать их локально, а затем открыть. У меня есть разрешение на доступ к сайту SharePoint, но у меня нет права администратора на настройку SharePoint (она управляется нашей ИТ-службой, а служба безопасности компании строго следит за защитой данных). Мы используем MFA для входа в наш сеанс Windows, и после этого мы можем получить доступ к SharePoint и другим службам без необходимости повторного ввода нашего пароля. До сих пор я использовал приведенный ниже код, и он все еще отлично работает:
using Microsoft.SharePoint.Client;
using OfficeDevPnP.Core;
string tempFileName = System.IO.Path.GetTempPath() + "filename.xlsx";
AuthenticationManager mgr = new AuthenticationManager();
ClientContext context = mgr.GetWebLoginClientContext("https://xxx.sharepoint.com/teams/mypage");
FileInformation fileinfo = File.OpenBinaryDirect(context, "ServerRealtivePath");
context.ExecuteQuery();
System.IO.FileStream fStream = new System.IO.FileStream(tempFileName, System.IO.FileMode.Create);
await fileinfo.Stream.CopyToAsync(fStream);
fStream.Close();
fileinfo.Stream.Close();
Так зачем пытаться починить то, что еще не сломано… пока? Пакет NuGet SharePointPnPCoreOnline, содержащий пространство имен OfficeDevPnP, теперь помечен как устаревший, и вместо него рекомендуется использовать PnPFramework. Но PnPFramework не содержит метода AuthenticationManager.GetWebLoginClientContext(). Учитывая постоянно растущую потребность в защите данных и новых технологиях, я ожидаю, что текущий метод в какой-то момент перестанет работать. Есть ли у вас эквивалентный способ подключения к точке доступа более современным способом?
У меня нет разрешения на регистрацию приложения в Azure, и я предполагаю, что наша ИТ-служба откажется от этого. Я не против попросить пользователя ввести свой логин в какой-то момент, если это необходимо. Я никогда не использовал REST или GRAPH API, но если это может помочь, я могу изучить его. Я хочу, чтобы право доступа к файлам основывалось на разрешении текущего пользователя. Если у пользователя нет разрешения на доступ к указанному файлу, я не хочу, чтобы приложение могло его загрузить.
Я открыт для предложений, спасибо
Для своего инструмента я только что переработал код из GetWebLoginClientContext
, он не большой и не сложный . Вот также более новая версия. Итак, что внутри: простая форма с управлением через веб-браузер (на основе Internet Explorer). Когда элемент управления браузера аутентифицирует пользователя, код получает файлы cookie проверки подлинности от элемента управления браузера с помощью API веб-браузера платформы и использует их в последующих вызовах SharePoint.
Что здесь может сломаться: Internet Explorer (и, следовательно, управление браузером) устарел, и его поддержка закончилась в прошлом году. Если окно проверки подлинности перестает работать при открытии из элемента управления браузера, это может быть проблемой. Я «исправил» это для себя, используя WebView2 вместо элемента управления браузера, и, поскольку он вечнозеленый, все должно быть в порядке. Он также предоставляет API для получения файлов cookie, которые нам нужны для вызова SharePoint.
Я не думаю, что подход с аутентификацией файлов cookie сам по себе является проблемой, но когда-нибудь они могут изменить файлы cookie, и тогда, возможно, потребуется соответствующим образом обновить приложение, если это произойдет.
Более «надежным» подходом было бы зарегистрировать приложение в Azure AD (на самом деле вам не обязательно просить своих администраторов зарегистрировать приложение, вы можете зарегистрировать его для себя, никого не спрашивая, в своей собственной «организации») .
При таком подходе пользователь должен дать согласие на использование приложения (чтобы разрешить приложению доступ к данным в организации). Может потребоваться согласие администратора, но это зависит от настроек организации (по умолчанию это не требуется, достаточно согласия пользователя).
Обратите внимание, что подключение с использованием «приложения» на самом деле более безопасно, потому что, когда вы предоставляете доступ к приложению, вы даете ему только определенные разрешения (т. е. вы получаете пересечение разрешений пользователя и разрешений, которые были предоставлены приложению). При подключении в качестве пользователя (т. е. с использованием описанного выше подхода «cookies») вы получаете полный доступ (т. е. вы можете делать все, что может пользователь).
Еще один момент: для приложения вам не нужно ничего создавать в Интернете (на самом деле веб-сайт не нужен); «URL-адрес обратного вызова» для получения токена доступа может размещаться в самом приложении (localhost) или приложение может быть настроено на использование кода устройства.
Очень поучительно, Спасибо! Я посмотрю, что я могу сделать с подходом к файлам cookie, так как он выглядит самым простым для меня. Но я обязательно рассмотрю более современный подход. Сначала мне нужно ознакомиться с Azure.