Criar aplicações Do SharePoint Embedded

  • 6 minutos

Os programadores podem criar aplicações que utilizam as poderosas capacidades de gestão de ficheiros e documentos no SharePoint através do SharePoint Embedded. Estes tipos de aplicações têm dois componentes distintos.

  • Um componente é responsável por realizar operações CRUD no SharePoint Embedded com as APIs do Microsoft Graph.
  • O outro componente implementa a interface para os utilizadores consumirem e armazenarem os documentos armazenados no SharePoint Embedded.

Introdução ao SharePoint Embedded

O SharePoint Embedded fornece uma forma mais rápida de os programadores criarem aplicações focadas em ficheiros e documentos. O SharePoint Embedded é alimentado pelo SharePoint. Os programadores podem integrar as mesmas poderosas capacidades de ficheiros e documentos que o SharePoint tem para oferecer nas suas próprias aplicações personalizadas.

Outra forma de ver o SharePoint Embedded é a sua aplicação personalizada utilizar o SharePoint para todas as funcionalidades de colaboração e armazenamento de documentos. Isto utiliza efetivamente o SharePoint Embedded como uma "API sem cabeça" para o sistema de armazenamento de documentos do SharePoint.

Os documentos da aplicação permanecem no inquilino do Microsoft 365

Quando um consumidor instala/regista uma aplicação Do SharePoint Embedded no respetivo inquilino do Microsoft 365, o SharePoint Embedded cria outra partição do SharePoint. Esta partição de armazenamento não tem uma interface de utilizador, mas os documentos na partição só são acessíveis através de APIs. Isto significa que todos os documentos estarão acessíveis ao ISV ou à aplicação do programador, mas os documentos só irão residir no inquilino do Microsoft 365 do consumidor.

As definições do Microsoft 365 para consumidores aplicam-se aos documentos da aplicação

Todos os documentos armazenados na partição do SharePoint criada pela aplicação SharePoint Embedded estão no inquilino do Microsoft 365 do consumidor e, por conseguinte, estão sujeitos às definições de inquilino do Microsoft 365 do consumidor.

Compreender diferentes tipos de permissões de aplicações e o fluxo On-Behalf-Of

Ao criar aplicações para que acedam a APIs REST como o Microsoft Graph e o SharePoint Online, diferentes tarefas requerem diferentes tipos de acesso. Para resolver este problema, o OAuth v2.0 é um padrão aberto de autorização utilizado para o acesso à API, incluindo o Microsoft Graph e o SharePoint Online. Fornece às aplicações acesso delegado a recursos protegidos em nome de um utilizador. Isto inclui dois tipos de permissões: App+User (também conhecido como Delegado) e Apenas Aplicação (ou Aplicação).

  • Permissões App+User (ou Delegated): este modelo tem a ver com um modelo de permissões de duas partes. A aplicação está a executar tarefas e a chamar APIs em nome de um utilizador com sessão iniciada. A aplicação obtém permissões delegadas do utilizador que inicia sessão na mesma, herdando os privilégios que o utilizador tem, incluindo quaisquer restrições como não conseguir aceder a determinados dados ou efetuar determinadas ações. Estas refletem as tarefas que o utilizador permitiu que a aplicação realizasse em seu nome durante a sessão.

    Por exemplo, pode ser dada permissão a uma aplicação para enviar um e-mail em nome de um utilizador, mas se o utilizador não tiver permissão para enviar um e-mail, a aplicação também não poderá enviá-la.

    Este tipo de permissão é frequentemente utilizado quando pretende que a sua aplicação funcione como o utilizador com sessão iniciada, em cenários de aplicação em que a interação é em nome de um utilizador e as permissões devem variar consoante o utilizador que concede o consentimento.

  • Permissões Apenas de Aplicação (ou Aplicação): as permissões apenas de aplicação são utilizadas, por outro lado, quando uma aplicação precisa de aceder a recursos independentemente de um utilizador. A aplicação obtém as permissões concedidas diretamente a si mesma, independentemente das permissões de utilizador. Permite que a aplicação aceda ao serviço de API com a sua própria identidade e privilégios. Isto é ideal para serviços em segundo plano ou daemons que são executados independentemente de uma sessão de utilizador.

Por exemplo, se tiver uma aplicação que precisa de aceder a todos os ficheiros numa biblioteca de documentos, mesmo aqueles que não são partilhados com nenhum utilizador, as permissões apenas de aplicações seriam a escolha certa.

As permissões de aplicação só podem ser consentidas por um administrador porque, muitas vezes, concedem privilégios mais elevados.

Além destas duas opções, um terceiro fluxo OAuth 2.0, On-Behalf-Of (também conhecido como fluxo OBO ) pode ser utilizado quando uma aplicação precisa de executar uma tarefa em nome do utilizador. Eis como funciona todo o fluxo OBO:

  1. Uma aplicação cliente autentica-se no servidor de autorização (como o Microsoft Entra ID) e pede um token de acesso para uma API (como o servidor de API do nosso projeto).
  2. O utilizador inicia sessão e permite que a aplicação atue em seu nome.
  3. A aplicação cliente recebe um token de acesso e um token de atualização que representa a sessão do utilizador.
  4. Quando a aplicação cliente tem de chamar outro serviço, como o SharePoint Online, em nome do utilizador, envia o token de acesso que obteve anteriormente no Authorization cabeçalho HTTP.
  5. A nossa API do lado do servidor valida o token de acesso e processa o pedido. Se precisar de chamar outro serviço (como o SharePoint Online) em nome do utilizador, obtém um token do Microsoft Entra ID ao apresentar este token já obtido.
  6. O Microsoft Entra ID emite um token de acesso "novo" para o SharePoint Online que o servidor de API do nosso projeto pode agora utilizar para chamar o SharePoint Online.

Num cenário prático que lida com o Microsoft Graph ou o SharePoint Online, quando um utilizador quer que uma aplicação aceda ao respetivo calendário, não é ideal que a aplicação inicie sessão para cada operação individual. Em vez disso, com o fluxo OBO, o utilizador só precisa de se autenticar uma vez e a aplicação realizará todas as operações autorizadas em seu nome.

Assim, o fluxo OBO simplifica a experiência do utilizador e melhora a segurança do sistema ao garantir que as permissões são validadas sempre que uma cadeia de chamadas é efetuada.

Resumo

Nesta secção, concluiu os passos iniciais para criar uma aplicação Web que irá realizar operações CRUD num Contentor Do SharePoint Embedded.