Mucha gracias Jose, yo podría implementar laravel passport con OpenId Connect segun entiendo es mas seguro ya que me genera un id_Token y usando openID Connect puedo enviar permisos directamente en el token. no se que tan necesario sea.
una ultima pregunta, en donde me recomenda almacenar este token, el cliente que consume esta desarrollado con React y Redux.
Bueno lo que pasa en que Passport usa oAuth2, nosotros aca estamos usando eso mismo, OpenID seria otra implementación de auth distinta por ende Passport ya no seria una opción. Creo que los 2 son cosas distintas. Si lo que quieres es usar un Auth server que implemente OpenID seria otra cosa. Ahora si quieres pasar los permisos directos al front puedes incluirlo como parte del user type. YA en el cliente Redux puede guardarlo en el store. No estoy seguro por que dices que el id_Token es mas seguro, de pronto una referencia o documentación me ayudaría para entender el razonamiento por que para los 2 son igual de seguros solo que son implementaciones distintas, con Passport implementas oAuth2 (en una forma GraphQL) y con open id ellos tienen su propio protocolo y especificación si no estoy mal.
En resumen, si lo que quieres es pasar los permisos al Front puedes agregarlos al user type
El middleware que se le aplique al query y al mutation es quien verifica si tiene o no el permiso para realizar la acción, pasando los permisos al front puedes controlar que el UI muestre o no cosas pero la validación del back es un si o si XD
Lo del Id_token era simplemente algo que escuche en un video por eso te preguntaba, ya que no sabia que eran implementaciones diferentes solo pense que se complementaban una con la otra.
listo jose muchas gracias entonces los permisos los incluyo en el user type pero de toda formas tengo que implementar el middleware en mutations y query
Jose Luis cada vez estoy mas interesado en el trabajo con graphql. A medida que avanzo aparecen nuevas inquietudes y ahora estoy revisando como hacer para que un solo middleware de autorizacion cubra todas las queries y mutations en lugar de indicarlo uno por uno
Hola, Pues middleware global se puede acá github.com/nuwave/lighthouse/blob/... pero hay que tener cuidado por que igual si necesita queries o mutations que no deba aplicar ese middleware ahi ya no le sirve esta solución.
Hola Jose, estoy trabajando el los middleware para toda la cuestion de cords, roles, autenticacion pero no entiendo muy bien como se implementa, por ejemplo tengo dentro de query:
Pero no entiendo de donde sale que va "auth:api", como seria para poner lo de roles , cords entre otros.
talvez si sabes alguna referencia o documentacion para poder entender bien esa cuestion de middleware con graphQl.
Muchas gracias, saludos.
Hola, Yo uso Spatie Permissions, hay un middleware que se puede aplicar para chequear el permiso al query o mutation. es solo usar la directive de middleware. lighthouse-php.com/3.7/api-referen... github.com/spatie/laravel-permission
Mucha gracias Jose, yo podría implementar laravel passport con OpenId Connect segun entiendo es mas seguro ya que me genera un id_Token y usando openID Connect puedo enviar permisos directamente en el token. no se que tan necesario sea.
una ultima pregunta, en donde me recomenda almacenar este token, el cliente que consume esta desarrollado con React y Redux.
Bueno lo que pasa en que Passport usa oAuth2, nosotros aca estamos usando eso mismo, OpenID seria otra implementación de auth distinta por ende Passport ya no seria una opción. Creo que los 2 son cosas distintas. Si lo que quieres es usar un Auth server que implemente OpenID seria otra cosa. Ahora si quieres pasar los permisos directos al front puedes incluirlo como parte del user type. YA en el cliente Redux puede guardarlo en el store. No estoy seguro por que dices que el id_Token es mas seguro, de pronto una referencia o documentación me ayudaría para entender el razonamiento por que para los 2 son igual de seguros solo que son implementaciones distintas, con Passport implementas oAuth2 (en una forma GraphQL) y con open id ellos tienen su propio protocolo y especificación si no estoy mal.
En resumen, si lo que quieres es pasar los permisos al Front puedes agregarlos al user type
El middleware que se le aplique al query y al mutation es quien verifica si tiene o no el permiso para realizar la acción, pasando los permisos al front puedes controlar que el UI muestre o no cosas pero la validación del back es un si o si XD
Lo del Id_token era simplemente algo que escuche en un video por eso te preguntaba, ya que no sabia que eran implementaciones diferentes solo pense que se complementaban una con la otra.
listo jose muchas gracias entonces los permisos los incluyo en el user type pero de toda formas tengo que implementar el middleware en mutations y query
Si claro, La validacion en el back es Obligatoria com Mayusculas hahahaha. Espero haber ayudado. Saludos!
Jose Luis cada vez estoy mas interesado en el trabajo con graphql. A medida que avanzo aparecen nuevas inquietudes y ahora estoy revisando como hacer para que un solo middleware de autorizacion cubra todas las queries y mutations en lugar de indicarlo uno por uno
Hola, Pues middleware global se puede acá github.com/nuwave/lighthouse/blob/... pero hay que tener cuidado por que igual si necesita queries o mutations que no deba aplicar ese middleware ahi ya no le sirve esta solución.
Hola Jose, estoy trabajando el los middleware para toda la cuestion de cords, roles, autenticacion pero no entiendo muy bien como se implementa, por ejemplo tengo dentro de query:
projects: [Project!]! @all(model: "App\Project") @middleware(checks:["auth:api"])
Pero no entiendo de donde sale que va "auth:api", como seria para poner lo de roles , cords entre otros.
talvez si sabes alguna referencia o documentacion para poder entender bien esa cuestion de middleware con graphQl.
Muchas gracias, saludos.
Hola,
Los globales se pueden poner en
github.com/laravel/laravel/blob/ma...
Y los que se aplican a cada tipo se puede poner en el schema definition
lighthouse-php.com/3.7/api-referen...
Saludos