Em circunstâncias normais, quando fazemos gerenciamento de direitos de acesso, salvamos as informações básicas do usuário após o login correto na sessão, e as recebemos toda vez que o usuário solicitar dados de página ou interface no futuro
Sessão para ver e comparar se ele está logado e se consegue acessar a página atual.
O princípio do Session é gerar um SessionID no lado do servidor correspondente aos dados armazenados do usuário, e o SessionID é armazenado em um cookie, e o cliente carregará isso consigo toda vez que for solicitado
Cookie, o servidor encontra os dados armazenados no lado do servidor com base no ID da sessão no cookie.
O FormsAuthentication é fornecido pela Microsoft para que nós, desenvolvedores, usemos para autenticação. Por meio dessa autenticação, podemos armazenar o nome de usuário e alguns dados de usuário em cookies,
A autenticação básica de identidade e função pode ser facilmente alcançada por meio de configurações básicas de condição.
O efeito a ser alcançado aqui é implementar o controle de acesso baseado em função usando o Authorize fornecido pelo sistema, sem usar a membresia.
1. Criar um Ticket
Após o login do usuário, o ID do usuário e o papel correspondente (para múltiplos papéis, separados) são armazenados no ticket.
Criptografe o chamado com FormsAuthentication.Encrypt.
Armazene o ticket criptografado no cookie de resposta (o js cliente não precisa ler esse cookie, então é melhor definir HttpOnly=True para evitar que ataques de navegador roubem e forjem cookies). Assim, você pode ler no cookie de Solicitação da próxima vez.
Uma demonstração simples é a seguinte:
bool isPersistent, //se deve persistir (definido conforme necessário, se configurado para persistência, a configuração Expires do cookie deve ser definida ao enviar um cookie)
O sexto parâmetro do FormsAuthenticationTicket armazena a string-de-tipo userData, onde o ID de papel do usuário atual é armazenado, separado por uma vírgula.
Ao fazer login com um nome de usuário "test", um cookie de log aparece no cliente
2. Obter informações de certificação
Após fazer login, na página de conteúdo, podemos obter as informações do uname pelo User.Identity.Name da solicitação atual, ou podemos descriptografar o cookie na solicitação para obter o ticket, e então obter o uname e userData (ou seja, as informações do ID de papel previamente armazenadas) dele.
3. Realizar controle de acesso por permissão por meio de atributos de anotação
Configure, Ativear Autenticação de Formulários e Gerenciamento de Funções no web.config
Quando adicionamos propriedades de anotação ao Controlador e à Ação, de onde obtemos o Papel definido? Como não usamos a autenticação baseada em Membros, também vamos criar um RoleProvider personalizado. O nome é CustomRoleProvider, herdado de RoleProvider. Aqui está a criação do seu próprio arquivo CustomRoleProvider.cs na pasta Helper sob o MVCApp.
Existem muitos métodos abstratos no RoleProvider, e nós só implementamos o método GetRolesForUser para obter papéis de usuário. O papel do usuário aqui pode ser consultado do banco de dados de acordo com o ID de usuário obtido, ou o que está armazenado na sessão ou no cookie. Aqui eu já armazenei o papel no userData do ticket, então vamos pegar a partir do ticket.
Se necessário, adicione atributos de anotação ao Controlador ou Ação validado, por exemplo, essa Ação só permite acesso com um RoleID de 1, 2 ou 3, e o RoleID do usuário atual é (7, 1, 8), o que significa que o usuário tem o direito de acesso.
P.S. :1. O Ticket é armazenado no momento de expiração do cookie, e se o navegador for fechado para lembrar o ticket atual, os parâmetros podem ser definidos quando o FormsAuthenticationTicket for instanciado.
2. A aquisição do Papel pode ser lida diretamente do banco de dados sem ser armazenada no userData do ticket, e o userData pode armazenar outras informações.
3. Se você quiser configurar de forma flexível os Papéis de Acesso Permitido do Controlador e da Ação, pode personalizar o método OnAuthorization na sobreposição AuthorizeAttribute, no qual o método é usado
Leia o ID de função permitido na página atual e verifique de acordo com o RoleID do usuário atual. Dessa forma, a configuração flexível do papel é realizada.
4. As informações no chamado acabam sendo armazenadas no cookie, e a segurança ainda fica a seu critério; pessoalmente, acho melhor armazenar o UserID e o RoleID na sessão.
|
Publicado em 19/07/2018 17:31:14
|
|
|
