Escrevendo uma página de logon de formulários personalizados para o SharePoint 2010 parte 1
Escrevendo uma página de logon de formulários personalizados para o SharePoint 2010 parte 1
No SharePoint 2007 escrever uma página de logon personalizado para um site de FBA (autenticação baseada em formulários) não era tão difícil. Há algumas coisas que você deve saber, a maioria delas não específica ao SharePoint, e algumas dicas para fazer com que o formulário de logon tenha a aparência de uma página de layouts padrão do SharePoint. No geral, se você conhecia ASP.NET e a classe FormsAuthentication estava no caminho certo. Por mais sorte que isso tenha sido, as coisas ficam um pouco mais complicadas no SharePoint 2010.
Nesta postagem, analisaremos um cenário de uma página de logon personalizada. Neste exemplo, decidimos que precisamos de uma página de logon totalmente personalizada – não vamos apenas mudar a aparência, precisamos de uma IU completamente diferente. Por exemplo, talvez precisemos das credenciais de Associação que usamos para fazer logon e talvez precisemos de alguém para inserir uma ID de autenticação secundária ID, como você teria com a SecurID. Nesse caso, teremos que ter algumas caixas de texto em uma página ASP.NET para o nome de usuário e a senha, e precisaremos utilizá-las para executar o logon do usuário programaticamente.
O ponto mais importante a ser lembrado aqui é que sua velha conhecida, a classe FormsAuthentication, não será mais usada. Isso ocorre porque no SharePoint 2010, os usuários da FBA são na verdade usuários de declarações. Assim, embora você talvez esteja pensando que está trabalhando com um usuário de Associação ASP.NET padrão e provedor de Funções, em segundo plano, esses objetos têm um shell de autenticação de declarações evidente. Por causa disso, precisamos usar algumas classes de declarações do SharePoint para trabalhar durante o processo de logon de FBA.
Preciso adicionar uma advertência aqui! Em geral, de uma forma ou de outra, antes de postar algo em meu blog, eu sei ou valido da melhor forma possível que essa é a maneira certa / abençoada / com suporte de fazer algo. Nesse caso, eu tentei repetidamente executar esse método, mas não consegui. Eu usei esse código para um projeto no qual estava trabalhando e ele não funciona, mas não quero que ninguém tenha um ataque se a patrulha do código disser depois que é necessário modificá-lo para seguir o procedimento melhor / mais apropriado de outra pessoa. Agora, vamos dar uma olhada em alguns códigos.
Antes de começarmos, há algumas referências de que vamos precisar, que você provavelmente ainda não usou. A primeira delas é uma Microsoft.SharePoint.Security.dll e ela está no hive 14 na pasta ISAPI. A outra é mais complexa e basicamente é o motivo pelo qual eu dei minha advertência acima. Você precisa de uma referência para a Microsoft.SharePoint.IdentityModel.dll. No entanto, se for adicionar referências, você não encontrará imediatamente esse assembly e, portanto, o motivo do meu ligeiro embaraço e e cautela ao mesmo tempo. Conforme descrevi em outra postagem, o melhor a fazer é encontrar esse item no sistema de arquivos, copiá-lo em um local fácil de encontrar e adicionar a referência à versão copiada. A maneira como geralmente faço isso, acho que porque sou da velha guarda, é abrir um prompt de comando, alterar a raiz da unidade e executar um “dir Microsoft.SharePoint.IdentityModel.dll /s” e encontrá-lo dessa forma. Depois que você tiver isso, provavelmente vai querer adicionar mais algumas instruções de uso:
using System.Web.Security;
using System.IdentityModel.Tokens;
using Microsoft.SharePoint;
using Microsoft.SharePoint.IdentityModel;
Então agora que eliminamos essa estranheza, quando eu usar a classe de declarações para validar as credenciais de usuário de FBA que o usuário digitou, deverei informar qual provedor de Associação e Função deverá ser usado. Somente um nome é necessário. No meu caso em particular, escrevi um provedor personalizado de Associação e Função para o que estava fazendo, portanto, apenas enumerei todos os provedores que meu aplicativo Web conhecia, até encontrar o meu:
//get the provider names for our type
string userProviderName = string.Empty;
string roleProviderName = string.Empty;
//get the membership provider name
foreach (MembershipProvider p in Membership.Providers)
{
if (p.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Users)))
{
userProviderName = p.Name;
break;
}
}
//get the role provider name
foreach (RoleProvider rp in System.Web.Security.Roles.Providers)
{
if (rp.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Roles)))
{
roleProviderName = rp.Name;
break;
}
}
Certo, ótimo, tenho os nomes dos meus provedores. Agora precisamos usar o nome de usuário e a senha para obter um SecurityToken. Para fazer isso, vamos usar a classe SPSecurityContext. Ela tem um método projetado apenas para executar esse logon de autenticação baseado em formulários para nós; se for bem-sucedido, ele retornará um SecurityToken – caso contrário, retornará nulo. Ele ficará assim quando as credenciais de usuário forem autenticadas:
SecurityToken tk = SPSecurityContext.SecurityTokenForFormsAuthentication(
new Uri(SPContext.Current.Web.Url), userProviderName, roleProviderName,
UserNameTxt.Text, PasswordTxt.Text);
Então eu passei um Uri para o site no qual estou tentando me autenticar, informei o nome dos meus provedores de associação e função e estou passando os valores de nome de usuário e senha que foram digitados nas caixas de texto da minha página de logon. Agora, preciso assegurar que meu SecurityToken não é nulo e, se não for, preciso escrever um token de sessão. Isso é feito com o SPFederationAuthenticationModule. Depois que eu escrevi meu token de sessão, posso prosseguir e redirecionar o usuário para a página ou o recurso solicitado. Aqui está o restante do código que faz isso
if (tk != null)
{
//try setting the authentication cookie
SPFederationAuthenticationModule fam = SPFederationAuthenticationModule.Current;
fam.SetPrincipalAndWriteSessionToken(tk);
//look for the Source query string parameter and use that as the redirection
string src = Request.QueryString["Source"];
if (!string.IsNullOrEmpty(src))
Response.Redirect(src);
}
else
{
StatusLbl.Text = "The credentials weren't valid or didn't work or something.";
}
Agora que terminei, você perceberá que só usei o parâmetro de cadeia de caracteres de consulta de origem porque ele nos informa para onde o usuário foi, originalmente. Quando tiver isso, basta deixar que as coisas sigam seu caminho.
Hopefully this helps you get going. Eu sei que foi uma luta encontrar a documentação sobre como fazer isso melhor durante a minha procura. Na parte 2, veremos como fazer isso de uma forma diferente e em outro cenário. Nesse caso, vamos querer que alguém confirme uma caixa do tipo “Concordo com os termos de uso deste site”, antes de usar o site pela primeira vez. Para fazer isso, estenderemos a página de logon básica e adicionaremos um manipulador na hora do logon.
Esta é uma postagem de blog traduzida. O artigo original pode ser encontrado em Escrevendo uma página de logon de formulários personalizados para o SharePoint 2010 parte 1