Closed masbicudo closed 11 years ago
O AuthorizationFilter tem que perceber que ele não existe e retornar um HttpUnauthorizedResult que vai mandar o cara pra tela de login de novo. Quando for Ajax, o servidor tem que retornar uma mensagem de erro padrão que já existe.
Esse filtro não faz nenhum acesso ao banco de dados... teria de abrir uma conexão com o banco lá para poder ver se o usuário existe. Essa seria a melhor alternativa, mas ai agente estaria usando duas sessões do entity no mesmo request... se isso não for uma regra, então dá pra fazer assim como você falou.
Se bem que pelo filterContext acho que dá pra acessar a mesma sessão que o controller usa.
Ou, se bem que eu to pensando aqui... se for para usar o filterContext
para ler a conexão do controller, então é melhor deixar o código no próprio controller, e mover isso para o método OnAuthorization
. O filtro só é uma vantagem quando ele é independente do controller, se ele for depender do controller, então não vale a pena usar o filtro.
Ainda assim, o que eu disse é valido, sobre retornar se o OnActionExecuting
da classe de base já tiver definido o result.
Ao dar override em
OnActionExecuting
de um controller, se após chamar obase.OnActionExecuting(filterContext)
o valor defilterContext.Result
for diferente de nulo, tem que retornar, e não fazer mais nada. Isso é necessário, pois é oCerebelloController
que faz signout e dá um resultHttpUnauthorizedResult
caso o usuário do cookie não exista mais.