Y cuando digo muy similar no estoy exagerando en absoluto, como podéis observar en el siguiente código:
[Authorize] public class AlertService : Hub { public void Alert(string msg) { this.Clients.All.showAlert(msg); } }
[Authorize]
. O mejor dicho, otro atributo [Authorize]
. Cuidado con esto, porque en un proyecto MVC4 con WebAPI y SignalR tendremos a nuestra disposición tres atributos con el mismo nombre, y si seleccionamos el namespace incorrecto será ignorado por completo, dejando libre el acceso al recurso que se intenta proteger. ¿Recordáis el famoso infierno de las DLL de antaño? Pues no va a ser nada comparado con el namespace hell que se está cociendo ;-D
Bueno, la cuestión es que aplicando este atributo a un Hub de la forma mostrada anteriormente impediremos el acceso a sus métodos a clientes que no hayan sido autenticados en el sistema. Si únicamente queremos efectuar este control en métodos concretos, bastará con decorarlos con
[Authorize]
de forma individualizada:public class AlertService: Hub { [Authorize] public void Alert(string msg) { this.Clients.All.showAlert(msg); } // Other hub methods }A la hora de introducir el atributo podemos ser aún más explícitos. Así, es posible permitir el acceso a un Hub o método a uno o varios usuarios separando su nombre por comas:
[Authorize(Users="fmercury,mjackson,fsinatra")] public void Sing(string msg) { // ... }O también podemos hacerlo por roles dentro del sistema:
[Authorize(Roles= "greatsingers")] public void Sing(string msg) { // ... }Por último, comentar que a diferencia de los homónimos atributos usados en MVC y WebAPI, este nuevo
Authorize
dispone de un parámetro booleano adicional llamado RequireOutGoing
que si establecemos a falso hará que las peticiones al método afectado sean ejecutadas sin necesidad de autenticación.Publicado en Variable not found.
No hay comentarios:
Publicar un comentario