mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-18 13:02:11 +03:00
37 lines
1.4 KiB
ReStructuredText
37 lines
1.4 KiB
ReStructuredText
|
Authentication / Access control
|
||
|
===============================
|
||
|
|
||
|
Hasura helps you define granular access controls for every field in your GraphQL schema, basically every table or
|
||
|
view in your Postgres schema. These access control rules can use dynamic variables that come in with every request.
|
||
|
|
||
|
.. image:: ../../../img/graphql/manual/auth/hasura-perms.png
|
||
|
|
||
|
**While developing**, you can send variables as request headers directly.
|
||
|
|
||
|
.. image:: ../../../img/graphql/manual/auth/dev-mode-auth.png
|
||
|
|
||
|
However, **in production**, when your application is deployed, your app can't send these authorization variables
|
||
|
directly!
|
||
|
|
||
|
Your app will likely only send an authorization token or cookie provided by your app's authentication
|
||
|
system to Hasura. In this case, Hasura will make a request to a webhook set up by you with the request headers your
|
||
|
app has sent (authorization tokens, cookies etc). The webhook should then return the variables required as context for
|
||
|
the access control rules. Alternatively, your app can send JWT tokens to Hasura which can be then decoded by Hasura to
|
||
|
get the variables required for the access control rules.
|
||
|
See :doc:`webhook` or :doc:`jwt` for more details.
|
||
|
|
||
|
Next, let's setup some :doc:`basic access control rules <basics>`.
|
||
|
|
||
|
See:
|
||
|
----
|
||
|
|
||
|
.. toctree::
|
||
|
:maxdepth: 1
|
||
|
|
||
|
basics
|
||
|
roles-variables
|
||
|
Permissions examples <common-roles-auth-examples>
|
||
|
webhook
|
||
|
webhook-examples
|
||
|
jwt
|