hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-09-21 07:28:26 +03:00
Code Issues Projects Releases Wiki Activity

docs: update image paths (#4649)

Browse Source
This commit is contained in:
Rikin Kachhia 2020-05-05 09:22:08 +05:30 committed by GitHub
parent 9d815598cc
commit dcab20a5ee
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
46 changed files with 139 additions and 139 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/graphql/manual/actions/action-connect.rst
View File

@ -94,7 +94,7 @@ You can create relationships for custom output types by:
Set the output type relationship as shown below:
.. thumbnail:: ../../../img/graphql/manual/actions/actions-relationship.png
.. thumbnail:: /img/graphql/manual/actions/actions-relationship.png
:alt: Console action relationship
Hit ``Save`` to create the relationship.

2
docs/graphql/manual/actions/action-permissions.rst
View File

@ -29,7 +29,7 @@ Set action permissions
Head to the ``Actions -> [action-name] -> Permissions`` tab in the
console.
.. thumbnail:: ../../../img/graphql/manual/actions/actions-permissions.png
.. thumbnail:: /img/graphql/manual/actions/actions-permissions.png
:alt: Console action permission
Hit ``Save`` to give the role permission to access the action.

8
docs/graphql/manual/actions/codegen.rst
View File

@ -41,7 +41,7 @@ Generating handler code for your action
You can select the framework of your choice to get the corresponding
handler boilerplate code.
.. thumbnail:: ../../../img/graphql/manual/actions/console-codegen-tab.png
.. thumbnail:: /img/graphql/manual/actions/console-codegen-tab.png
:alt: Console codegen tab
@ -59,17 +59,17 @@ Generating handler code for your action
1. Choose which framework you want to codegen for:
.. thumbnail:: ../../../img/graphql/manual/actions/cli-framework-prompt.png
.. thumbnail:: /img/graphql/manual/actions/cli-framework-prompt.png
:alt: CLI Framework Prompt
2. Choose if you also wish to clone a starter kit for the chosen framework:
.. thumbnail:: ../../../img/graphql/manual/actions/cli-starter-kit-prompt.png
.. thumbnail:: /img/graphql/manual/actions/cli-starter-kit-prompt.png
:alt: CLI Starter Kit Prompt
3. Choose a path where you want to output the auto-generated code files
.. thumbnail:: ../../../img/graphql/manual/actions/cli-output-dir-prompt.png
.. thumbnail:: /img/graphql/manual/actions/cli-output-dir-prompt.png
:alt: CLI Starter Kit Prompt

4
docs/graphql/manual/actions/create.rst
View File

@ -96,7 +96,7 @@ in the GraphQL schema.
Go to the ``Actions`` tab on the console and click on ``Create``. This will
take you to a page like this:
.. thumbnail:: ../../../img/graphql/manual/actions/mutation-action-create.png
.. thumbnail:: /img/graphql/manual/actions/mutation-action-create.png
:alt: Console action create
:width: 70%
@ -270,7 +270,7 @@ the GraphQL schema.
Go to the ``Actions`` tab on the console and click on ``Create``. This will
take you to a page like this:
.. thumbnail:: ../../../img/graphql/manual/actions/query-action-create.png
.. thumbnail:: /img/graphql/manual/actions/query-action-create.png
:alt: Console action create
:width: 70%

6
docs/graphql/manual/actions/derive.rst
View File

@ -75,13 +75,13 @@ derive our action:
Next hit the ``Derive action`` button as shown below:
.. thumbnail:: ../../../img/graphql/manual/actions/actions-derive-button.png
.. thumbnail:: /img/graphql/manual/actions/actions-derive-button.png
:alt: Console derive action button
This will redirect you to the ``Add a new action`` page with the action
definition auto filled.
.. thumbnail:: ../../../img/graphql/manual/actions/actions-derive-types.png
.. thumbnail:: /img/graphql/manual/actions/actions-derive-types.png
:alt: Console derived action types
@ -149,7 +149,7 @@ the action back to the original operation.
You can select the framework of your choice to get the corresponding
handler boilerplate code.
.. thumbnail:: ../../../img/graphql/manual/actions/actions-derive-codegen.png
.. thumbnail:: /img/graphql/manual/actions/actions-derive-codegen.png
:alt: Console derived action codegen
.. note::

2
docs/graphql/manual/actions/index.rst
View File

@ -20,7 +20,7 @@ logic using custom queries and mutations. Actions can be
added to Hasura to handle various use cases such as data validation, data
enrichment from external sources and any other complex business logic.
.. thumbnail:: ../../../img/graphql/manual/actions/actions-arch.png
.. thumbnail:: /img/graphql/manual/actions/actions-arch.png
:class: no-shadow
:alt: Actions high level architecture

4
docs/graphql/manual/auth/authentication/index.rst
View File

@ -39,7 +39,7 @@ rules.
Here's how a GraphQL request is processed in webhook mode:
.. thumbnail:: ../../../../img/graphql/manual/auth/auth-webhook-overview.png
.. thumbnail:: /img/graphql/manual/auth/auth-webhook-overview.png
:alt: Authentication using webhooks
2. JWT (JSON Web Token)
@ -51,7 +51,7 @@ evaluate access control rules.
Here's how a GraphQL query is processed in JWT mode:
.. thumbnail:: ../../../../img/graphql/manual/auth/auth-jwt-overview.png
.. thumbnail:: /img/graphql/manual/auth/auth-jwt-overview.png
:alt: Authentication using JWT
**See more details at:**

4
docs/graphql/manual/auth/authentication/jwt.rst
View File

@ -21,7 +21,7 @@ The idea is that your auth server will return JWT tokens, which are decoded and
verified by the GraphQL engine, to authorize and get metadata about the request
(``x-hasura-*`` values).
.. thumbnail:: ../../../../img/graphql/manual/auth/jwt-auth.png
.. thumbnail:: /img/graphql/manual/auth/jwt-auth.png
:alt: Authentication using JWT
The JWT is decoded, the signature is verified, then it is asserted that the
@ -543,7 +543,7 @@ https://hasura.io/jwt-config.
The config generated from this page can be directly pasted in yaml files and command line arguments as it takes
care of escaping new lines.
.. thumbnail:: ../../../../img/graphql/manual/auth/jwt-config-generated.png
.. thumbnail:: /img/graphql/manual/auth/jwt-config-generated.png
:width: 75%
:alt: Generating JWT config

2
docs/graphql/manual/auth/authentication/webhook.rst
View File

@ -17,7 +17,7 @@ Introduction
You can configure the GraphQL engine to use a webhook to authenticate all incoming requests to the Hasura GraphQL engine server.
.. thumbnail:: ../../../../img/graphql/manual/auth/webhook-auth.png
.. thumbnail:: /img/graphql/manual/auth/webhook-auth.png
:alt: Authentication using webhooks
.. admonition:: Prerequisite

8
docs/graphql/manual/auth/authorization/basics.rst
View File

@ -18,7 +18,7 @@ Introduction
To understand the basics of access control in Hasura, let's take a look at this analogy to a SQL query:
.. thumbnail:: ../../../../img/graphql/manual/auth/permissions-rule-analogy.png
.. thumbnail:: /img/graphql/manual/auth/permissions-rule-analogy.png
:width: 70%
:alt: Understanding access control in Hasura
@ -80,7 +80,7 @@ Head to the ``GraphiQL`` tab in your console and try out the below query:
You'll see that this results in a response that contains all the authors because by default the GraphQL
query is accepted with **admin** permissions.
.. thumbnail:: ../../../../img/graphql/manual/auth/fetch-authors.png
.. thumbnail:: /img/graphql/manual/auth/fetch-authors.png
:alt: Run a query without access control
Define access control rules
@ -90,7 +90,7 @@ Now let's define an access control rule for the ``author`` table for a role ``us
**Permissions** section of the table (``Data`` --> <table> --> ``Permissions`` tab) and define permissions
as shown below:
.. thumbnail:: ../../../../img/graphql/manual/auth/permission-basics-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/permission-basics-simple-example.png
:alt: Define access control rules
This permission rule reads as: "*For the role* ``user`` *, table* ``author`` *and operation* ``select``/``query``,
@ -103,7 +103,7 @@ Let's run the same query as above but now with the ``X-Hasura-Role`` and ``X-Has
variables also included to indicate role and user information. These session variables are passed in
the ``Request Headers`` section of ``GraphiQL`` as highlighted below:
.. thumbnail:: ../../../../img/graphql/manual/auth/permission-basics-query-with-access-control.png
.. thumbnail:: /img/graphql/manual/auth/permission-basics-query-with-access-control.png
:alt: Run a query with access control
As you can see, the results are now filtered based on the access control rule for the role ``user``

24
docs/graphql/manual/auth/authorization/common-roles-auth-examples.rst
View File

@ -31,7 +31,7 @@ Anonymous (not logged in) users
- Choose the right set of columns that will get exposed in the GraphQL schema as fields. Ensure that sensitive
information will not be exposed.
.. thumbnail:: ../../../../img/graphql/manual/auth/anonymous-role-examples.png
.. thumbnail:: /img/graphql/manual/auth/anonymous-role-examples.png
:class: no-shadow
:alt: Access control for an anonymous role
@ -47,7 +47,7 @@ Logged-in users
- Note that the ``X-Hasura-User-Id`` is a :ref:`dynamic session variable<roles_variables>` that comes in from
your :ref:`auth webhook's <auth_webhooks>` response, or as a request header if you're testing.
.. thumbnail:: ../../../../img/graphql/manual/auth/user-select-graphiql.png
.. thumbnail:: /img/graphql/manual/auth/user-select-graphiql.png
:class: no-shadow
:alt: Access control for a logged-in user
@ -64,7 +64,7 @@ organisation either in the same table or via a related table.
- ``X-Hasura-Org-Id`` is a :ref:`dynamic variable <roles_variables>` that is returned by your
:ref:`auth webhook <auth_webhooks>` for an incoming GraphQL request.
.. thumbnail:: ../../../../img/graphql/manual/auth/org-manager-graphiql.png
.. thumbnail:: /img/graphql/manual/auth/org-manager-graphiql.png
:class: no-shadow
:alt: Access control for a manager of an organisation
@ -84,7 +84,7 @@ Let's say the "ownership" or "visibility" information for a data model (table) i
- This reads as: Allow the role collaborator to select if ``article.collaborators`` has a ``collaborator_id``
equal to that of ``X-Hasura-User-Id``.
.. thumbnail:: ../../../../img/graphql/manual/auth/collaborator-relationship.png
.. thumbnail:: /img/graphql/manual/auth/collaborator-relationship.png
:class: no-shadow
:alt: Access control for collaborators of an article
@ -149,7 +149,7 @@ Database Schema
The following is a reference database schema for our example:
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-db-schema.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-db-schema.png
:alt: Database schema example for multiple roles per user
Based on this schema, we'll create the following tables:
@ -196,7 +196,7 @@ Relationships
Create an array relationship named ``reviewers`` based on the foreign key constraint ``reviewers`` :: ``article_id`` → ``articles`` :: ``id``:
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-reviewers-array-relationship.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-reviewers-array-relationship.png
:class: no-shadow
:alt: Create an array relationship
@ -240,7 +240,7 @@ Permissions for role ``author``
b) :ref:`Column presets <column_presets>`: Session-variable-based column preset for the ``author_id`` column to automatically insert the user's ID i.e. the ``X-Hasura-User-Id`` session-variable's value. It also helps us avoid explicitly passing the user's ID in the insert mutation.
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-author-insert.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-author-insert.png
:alt: Permissions for the role author
Notice how we don't need to have an explicit row-level permission (*a custom check*) as only authenticated users with the role ``author`` can perform this action. As we have a column preset for the ``author_id`` column that automatically takes the author's ID (*and the* ``id`` *column is an auto-increment integer field*), we only need to allow access to the ``title`` column.
@ -249,7 +249,7 @@ Permissions for role ``author``
Again, we'll use **column-level** permissions to restrict access to certain columns. Additionally, we need to define row-level permissions (*a custom check*) to restrict access to only those articles authored by the current user:
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-author-select.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-author-select.png
:alt: Column access for the role author
The row-level permission rule shown here translates to "*if the value in the* ``author_id`` *column of this row is equal to the user's ID i.e. the* ``X-Hasura-User-Id`` *session-variable's value, allow access to it*".
@ -261,7 +261,7 @@ Permissions for role ``reviewer``
For this use-case, we'll use :ref:`relationship or nested-object permissions<relationships-in-permissions>` based on the array relationship ``reviewers`` to restrict access to assigned articles only.
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-reviewer-update.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-reviewer-update.png
:alt: Permissions for the role reviewer
The array-relationship based permission rule in the above image reads as "*if the ID of any reviewer assigned to this article is equal to the user's ID i.e. the* ``X-Hasura-User-Id`` *session-variable's value, allow access to it*". The columns' access is restricted using the column-level permissions highlighted above.
@ -270,7 +270,7 @@ Permissions for role ``reviewer``
This permission rule is pretty much the same as the one for update, the only difference being the column-level permissions.
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-reviewer-select.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-reviewer-select.png
:alt: Column access for the role reviewer
Permissions for role ``editor``
@ -280,14 +280,14 @@ Permissions for role ``editor``
This is a straightforward rule - there's no need for any row-level permissions since editors have access to all rows and they can *read* all columns.
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-editor-select.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-editor-select.png
:alt: Permissions for the role editor
* **Allow editors to update an article**
There's no need for row-level permissions in this case either but we need to restrict access to certain columns only:
.. thumbnail:: ../../../../img/graphql/manual/auth/multirole-example-editor-update.png
.. thumbnail:: /img/graphql/manual/auth/multirole-example-editor-update.png
:alt: Column access for the role editor

2
docs/graphql/manual/auth/authorization/index.rst
View File

@ -23,7 +23,7 @@ session variables. Other session variables can be passed by your auth service as
**For example:**
.. thumbnail:: ../../../../img/graphql/manual/auth/hasura-perms.png
.. thumbnail:: /img/graphql/manual/auth/hasura-perms.png
:width: 80 %
:alt: Create a permission rule

2
docs/graphql/manual/auth/authorization/modeling-roles.rst.wip
View File

@ -18,7 +18,7 @@ Roles can be typically be modeled in two ways:
1. **Hierarchical roles**: Access scopes are nested depending on available roles. `Roles in Github for organisations <https://help.github.com/en/articles/managing-peoples-access-to-your-organization-with-roles>`_
is a great example of such modelling where access scopes are inherited by deeper roles:
.. thumbnail:: ../../../../img/graphql/manual/auth/github-org-hierarchical-roles.png
.. thumbnail:: /img/graphql/manual/auth/github-org-hierarchical-roles.png
2. **Flat roles**: Non-hierarchical roles with each role requiring an independent access scope to be defined.

24
docs/graphql/manual/auth/authorization/permission-rules.rst
View File

@ -18,7 +18,7 @@ Introduction
Access control rules in Hasura are defined at a role, table and action (*insert, update, select, delete*)
level granularity:
.. thumbnail:: ../../../../img/graphql/manual/auth/permission-rule-granularity.png
.. thumbnail:: /img/graphql/manual/auth/permission-rule-granularity.png
:alt: Access control rules in Hasura
Requests to Hasura should contain the reserved session variable ``X-Hasura-Role`` to indicate the requesting
@ -108,11 +108,11 @@ See the :ref:`API reference <MetadataOperator>` for a list of all supported colu
types:
.. thumbnail:: ../../../../img/graphql/manual/auth/operators-for-integer-types.png
.. thumbnail:: /img/graphql/manual/auth/operators-for-integer-types.png
:width: 40%
:alt: Column operators for integer types
.. thumbnail:: ../../../../img/graphql/manual/auth/operators-for-text-types.png
.. thumbnail:: /img/graphql/manual/auth/operators-for-text-types.png
:width: 40%
:alt: Column operators for text types
@ -122,19 +122,19 @@ Using boolean expressions
The following is an example of a simple boolean expression to restrict access for ``select`` to rows where
the value in the ``id`` column is greater than 10:
.. thumbnail:: ../../../../img/graphql/manual/auth/simple-boolean-expression.png
.. thumbnail:: /img/graphql/manual/auth/simple-boolean-expression.png
:alt: Using boolean expressions to build rules
You can construct more complex boolean expressions using the ``_and``, ``_or`` and ``not`` operators:
.. thumbnail:: ../../../../img/graphql/manual/auth/boolean-operators.png
.. thumbnail:: /img/graphql/manual/auth/boolean-operators.png
:alt: Using more complex boolean expressions to build rules
**For example**, using the ``_and`` operator, you can construct a rule to restrict access for ``select`` to rows where
the value in the ``id`` column is greater than 10 **and** the value in the ``name`` column starts with "a"
or "A":
.. thumbnail:: ../../../../img/graphql/manual/auth/composite-boolean-expression.png
.. thumbnail:: /img/graphql/manual/auth/composite-boolean-expression.png
:alt: Example of a rule with the _and operator
Using session variables
@ -148,7 +148,7 @@ to construct a rule to restrict access for ``select`` to rows in the ``articles`
``id`` column is equal to the value in the session variable (*assuming this variable is being used to indicate
the author's ID*):
.. thumbnail:: ../../../../img/graphql/manual/auth/session-variables-in-permissions-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/session-variables-in-permissions-simple-example.png
:alt: Using session variables to build rules
.. _relationships-in-permissions:
@ -164,7 +164,7 @@ called ``agent`` (*an author can have an agent*) and we want to allow users with
the details of the authors who they manage in ``authors`` table. We can define the following permission rule
that uses the aforementioned object relationship:
.. thumbnail:: ../../../../img/graphql/manual/auth/nested-object-permission-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/nested-object-permission-simple-example.png
:alt: Using a nested object to build rules
This permission rule reads as "*if the author's agent's* ``id`` *is the same as the requesting user's*
@ -191,7 +191,7 @@ our table.
column in the ``users`` table is set to ``true``. Let's assume the user's id is passed in the ``X-Hasura-User-ID``
session variable.
.. thumbnail:: ../../../../img/graphql/manual/auth/exists-permission-example.png
.. thumbnail:: /img/graphql/manual/auth/exists-permission-example.png
:alt: Use an unrelated table to build rules
This permission rule reads as "*if there exists a row in the table* ``users`` *whose* ``id`` *is the same as the requesting user's*
@ -204,7 +204,7 @@ Column-level permissions
Column-level permissions determine access to columns in the rows that are accessible based on row-level
permissions. These permissions are simple selections:
.. thumbnail:: ../../../../img/graphql/manual/auth/column-level-permissions.png
.. thumbnail:: /img/graphql/manual/auth/column-level-permissions.png
:alt: Column level permissions
In this example, the role ``author`` has only partial access to columns of the accessible rows for
@ -218,7 +218,7 @@ Row fetch limit
In the case of ``select`` operations, the number of rows to be returned in the response can be limited
using this configuration:
.. thumbnail:: ../../../../img/graphql/manual/auth/limit-rows-for-select.png
.. thumbnail:: /img/graphql/manual/auth/limit-rows-for-select.png
:alt: Row fetch limit
In the above example, this configuration restricts the number of accessible rows (*based on the rule*:
@ -232,7 +232,7 @@ Aggregation queries permissions
In the case of ``select`` operations, access to :ref:`aggregation queries <aggregation_queries>`
can be restricted for a given role using this configuration.
.. thumbnail:: ../../../../img/graphql/manual/auth/aggregation-query-permissions.png
.. thumbnail:: /img/graphql/manual/auth/aggregation-query-permissions.png
:alt: Aggregation queries permissions
In the above example, the role ``user`` is allowed to make aggregation queries.

24
docs/graphql/manual/auth/authorization/reference-permissions.rst.wip
View File

@ -13,7 +13,7 @@ How permissions work
Access control rules in Hasura are defined at a role, table and action (*insert, update, select, delete*) level granulaity:
.. thumbnail:: ../../../../img/graphql/manual/auth/permission-rule-granularity.png
.. thumbnail:: /img/graphql/manual/auth/permission-rule-granularity.png
Requests to Hasura should contain the reserved session variable ``X-Hasura-Role`` to indicate the requesting user's role, and the table and action information is inferred from the request itself. This information is used to determine the right permission rule to be applied (*if one has been defined*) to the incoming request.
@ -65,7 +65,7 @@ If you make this query as an admin in the Graphiql section of the console and cl
Let's say you now define the following permission rule on the ``authors`` table (*as described in the example* :doc:`here <basics>`):
.. thumbnail:: ../../../../img/graphql/manual/auth/permission-basics-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/permission-basics-simple-example.png
If you were to run the same query with the role ``user`` (``X-Hasura-Role`` = ``user``) and as a user with ``id`` = ``1`` (``X-Hasura-User-ID`` = ``1``) and hit the **Analyze** button, you will see the following generated SQL:
@ -149,24 +149,24 @@ Type-based operators (*depending on the column type*) are available for construc
E.g. the following two images illustrate the different operators available for ``integer`` and ``text`` types:
.. thumbnail:: ../../../../img/graphql/manual/auth/operators-for-integer-types.png
.. thumbnail:: /img/graphql/manual/auth/operators-for-integer-types.png
.. thumbnail:: ../../../../img/graphql/manual/auth/operators-for-text-types.png
.. thumbnail:: /img/graphql/manual/auth/operators-for-text-types.png
**Using boolean expressions**
#############################
The following is an example of a simple boolean expression to restrict access for ``select`` to rows where the value in the ``id`` column is greater than 10:
.. thumbnail:: ../../../../img/graphql/manual/auth/simple-boolean-expression.png
.. thumbnail:: /img/graphql/manual/auth/simple-boolean-expression.png
You can construct more complex boolean expression using the ``_and``, ``_or`` and ``not`` operators:
.. thumbnail:: ../../../../img/graphql/manual/auth/boolean-operators.png
.. thumbnail:: /img/graphql/manual/auth/boolean-operators.png
E.g. using the ``_and`` operator, you can construct a rule to restrict access for ``select`` to rows where the value in the ``id`` column is greater than 10 **and** the value in the ``name`` column starts with "a" or "A":
.. thumbnail:: ../../../../img/graphql/manual/auth/composite-boolean-expression.png
.. thumbnail:: /img/graphql/manual/auth/composite-boolean-expression.png
.. Using roles
.. ###########
@ -179,7 +179,7 @@ Session variable, that have been resolved from authentication tokens by either y
E.g. to allow an ``author`` to access only their articles, you can use the ``X-Hasura-User-ID`` session variable to construct a rule to restrict access for ``select`` to rows in the ``articles`` table where the value in the ``id`` column is equal to the value in the session variable (*assuming this variable is being used to indicate the author's ID*):
.. thumbnail:: ../../../../img/graphql/manual/auth/session-variables-in-permissions-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/session-variables-in-permissions-simple-example.png
.. _relationships-in-permissions:
@ -190,7 +190,7 @@ You can leverage :doc:`relationships <../../schema/relationships/index>` to defi
For e.g. let's say you have an object relationship called ``agent`` from the ``authors`` table to another table called ``agent`` (*an author can have an agent*) and we want to allow users with the role ``agent`` to access the details of the authors who they manage in ``authors`` table. We can define the following permission rule that uses the aforementioned object relationship:
.. thumbnail:: ../../../../img/graphql/manual/auth/nested-object-permission-simple-example.png
.. thumbnail:: /img/graphql/manual/auth/nested-object-permission-simple-example.png
This permission rule reads as "*if the author's agent's* ``id`` *is the same as the requesting user's* ``id`` *, allow access to the author's details*.
@ -208,7 +208,7 @@ Column-level permissions
^^^^^^^^^^^^^^^^^^^^^^^^
Column-level permissions determine access to columns in the rows that accessible based on row-level permissions. These permissions are simple selections:
.. thumbnail:: ../../../../img/graphql/manual/auth/column-level-permissions.png
.. thumbnail:: /img/graphql/manual/auth/column-level-permissions.png
In this example, the role ``author`` has only partial access to columns of the accessible rows for the ``select`` operation.
@ -219,7 +219,7 @@ Limiting number of rows
In the case of ``select`` operations, the number of rows to be returned in the response can be limited using this configuration:
.. thumbnail:: ../../../../img/graphql/manual/auth/limit-rows-for-select.png
.. thumbnail:: /img/graphql/manual/auth/limit-rows-for-select.png
In the above example, this configuration restricts the number of accessible rows (*based on the rule*: ``{"id":{"_eq":"X-Hasura-User-Id"}}``) to 20.
@ -230,7 +230,7 @@ Aggregation queries permissions
In the case of ``select`` operations, access to :doc:`aggregation queries <../../queries/aggregation-queries>` can be restricted for a given role using this configuration.
.. thumbnail:: ../../../../img/graphql/manual/auth/aggregation-query-permissions.png
.. thumbnail:: /img/graphql/manual/auth/aggregation-query-permissions.png
In the above example, the role ``user`` is allowed to make aggregation queries.

6
docs/graphql/manual/auth/authorization/role-multiple-rules.rst
View File

@ -53,7 +53,7 @@ Step 2: Create a relationship
For the table ``user_info``, :ref:`create a manual object relationship <create_manual_relationships>` called
``private_info`` using ``user_info : id -> user_private : user_id``:
.. thumbnail:: ../../../../img/graphql/manual/auth/multiple-rules-create-manual-relationship.png
.. thumbnail:: /img/graphql/manual/auth/multiple-rules-create-manual-relationship.png
:alt: Create a manual object relationship
Step 3: Define permissions
@ -63,13 +63,13 @@ For the role ``user``, create the following permissions for ``select``:
- Table ``user_info``: allow access to ``id``, ``name`` and ``city`` without any row conditions.
.. thumbnail:: ../../../../img/graphql/manual/auth/multiple-rules-define-public-permissions.png
.. thumbnail:: /img/graphql/manual/auth/multiple-rules-define-public-permissions.png
:alt: Column access for the role user
- View ``user_private``: allow access to ``id``, ``phone``, ``email`` and ``address`` if the ``user-id``
passed in the session variable is equal to the row's ``user_id``.
.. thumbnail:: ../../../../img/graphql/manual/auth/multiple-rules-define-private-permissions.png
.. thumbnail:: /img/graphql/manual/auth/multiple-rules-define-private-permissions.png
:alt: Column access for the role user based on row level permissions
Step 4: Query with appropriate access control

2
docs/graphql/manual/auth/authorization/roles-variables.rst
View File

@ -104,7 +104,7 @@ Roles are typically modelled in two ways:
1. **Hierarchical roles**: Access scopes are nested depending on available roles. `Roles in Github for organisations <https://help.github.com/en/articles/managing-peoples-access-to-your-organization-with-roles>`_
is a great example of such modelling where access scopes are inherited by deeper roles:
.. thumbnail:: ../../../../img/graphql/manual/auth/github-org-hierarchical-roles.png
.. thumbnail:: /img/graphql/manual/auth/github-org-hierarchical-roles.png
:alt: Hierarchical roles
2. **Flat roles**: Non-hierarchical roles with each role requiring an independent access scope to be defined.

18
docs/graphql/manual/auth/authorization/use-cases.rst.wip
View File

@ -18,7 +18,7 @@ Head to the ``Permissions`` tab of the ``author`` table.
Now add a ``select`` access control rule for the ``user`` role on the ``author`` table:
.. thumbnail:: ../../../../img/graphql/manual/auth/author-select-perms.png
.. thumbnail:: /img/graphql/manual/auth/author-select-perms.png
This rule reads as:
@ -44,7 +44,7 @@ This rule reads as:
Now, let's make the same query as above but also include two dynamic authorization variables ``X-Hasura-Role`` and
``X-Hasura-User-Id`` via request headers. These will automatically get used according to the permission rule we set up.
.. thumbnail:: ../../../../img/graphql/manual/auth/query-with-perms.png
.. thumbnail:: /img/graphql/manual/auth/query-with-perms.png
You can notice above how the same query now only includes the right slice of data.
@ -83,7 +83,7 @@ We can restrict the columns of a table that a particular role has access to.
Head to the ``Permissions`` tab of the table and edit the ``Select`` permissions for the role:
.. thumbnail:: ../../../../img/graphql/manual/auth/restrict-columns.png
.. thumbnail:: /img/graphql/manual/auth/restrict-columns.png
.. _limit_rows:
@ -94,7 +94,7 @@ We can set a hard limit on the maximum number of rows that will be returned in a
Head to the ``Permissions`` tab of the table and edit the ``Select`` permissions for the role:
.. thumbnail:: ../../../../img/graphql/manual/auth/limit-results.png
.. thumbnail:: /img/graphql/manual/auth/limit-results.png
.. _using-relationships-in-permissions:
@ -105,16 +105,16 @@ You can leverage relationships to define permission rules with fields from a nes
* An author/articles schema where an article can have one or more reviewers i.e. users with the role ``reviewer`` can only edit those articles that have been assigned to them:
.. thumbnail:: ../../../../img/graphql/manual/auth/schema-for-nested-object-based-permissions.png
.. thumbnail:: /img/graphql/manual/auth/schema-for-nested-object-based-permissions.png
* The foreign key constraint from ``reviewers`` :: ``article_id`` → ``articles`` :: ``id`` is used for an array relationship called ``reviewers`` in the ``articles`` table:
.. thumbnail:: ../../../../img/graphql/manual/auth/array-relationship-reviewers.png
.. thumbnail:: /img/graphql/manual/auth/array-relationship-reviewers.png
:class: no-shadow
We can use this relationship in a permission rule for the ``articles`` table to limit access for users with the role ``reviewer`` to only assigned rows:
.. thumbnail:: ../../../../img/graphql/manual/auth/nested-object-permissions-rule.gif
.. thumbnail:: /img/graphql/manual/auth/nested-object-permissions-rule.gif
Via the relationship, we are using the ``reviewer_id`` field of the nested object ``reviewers`` in the the above permission rule that reads as "Allow updating an article if the **reviewer_id of any of the reviewers assigned to this article** is the same as the requesting user's id (*which is sent in the resolved session variable* ``X-Hasura-User-ID``)".
@ -144,12 +144,12 @@ Let's say we have the following test data for the list of reviewers:
Applying the above permission rule for "update" to "select" operation also, let's query the ``articles`` table to watch this permission rule in action:
.. thumbnail:: ../../../../img/graphql/manual/auth/restricted-data-for-role-reviewer.png
.. thumbnail:: /img/graphql/manual/auth/restricted-data-for-role-reviewer.png
:class: no-shadow
As we've made this query with the role ``reviewer`` and user ID ``5`` (*highlighted in the request headers in the above image*), we can only query those articles for which this user is a reviewer. This will be the case for update mutations too. As the user with id ``5`` does not have access to article with id ``2`` (*refer to the table above*), the following mutation will not update any rows of the ``articles`` table:
.. thumbnail:: ../../../../img/graphql/manual/auth/unsuccessful-mutation-for-role-reviewer.png
.. thumbnail:: /img/graphql/manual/auth/unsuccessful-mutation-for-role-reviewer.png
:class: no-shadow
.. admonition:: Array and Object relationships work similarly

2
docs/graphql/manual/auth/index.rst
View File

@ -15,7 +15,7 @@ Authentication & Authorization
In Hasura, access control or authorization is based on **roles**. Let's take a look at how this works
when the GraphQL engine receives a request:
.. thumbnail:: ../../../img/graphql/manual/auth/auth-high-level-overview.png
.. thumbnail:: /img/graphql/manual/auth/auth-high-level-overview.png
:alt: Authentication and authorization with Hasura
As you can see from this:

6
docs/graphql/manual/business-logic/index.rst.wip
View File

@ -15,7 +15,7 @@ GraphQL engine/Postgres, different avenues are recommended for introducing such
- **Post-CRUD**: :ref:`event-triggers`
- :ref:`derived-data`
.. thumbnail:: ../../../img/graphql/manual/business-logic/custom-business-logic.png
.. thumbnail:: /img/graphql/manual/business-logic/custom-business-logic.png
.. _remote-schemas:
@ -35,7 +35,7 @@ To support these kinds of business logic, a custom GraphQL schema with resolvers
logic is needed (*see link below for boilerplates*). This remote schema can then be merged with GraphQL engine's
schema using the console. Here's a reference architecture diagram for such a setup:
.. thumbnail:: ../../../img/graphql/manual/schema/schema-stitching-v1-arch-diagram.png
.. thumbnail:: /img/graphql/manual/schema/schema-stitching-v1-arch-diagram.png
For more details, links to boilerplates for custom GraphQL servers, etc. please head to :doc:`../remote-schemas/index`.
@ -56,7 +56,7 @@ If your business logic is stateful, it can even store its state back in the Post
with GraphQL engine, allowing your frontend app to offer a reactive user experience, where the app uses GraphQL
subscriptions to listen to updates from your webhook via Postgres.
.. thumbnail:: ../../../img/graphql/manual/event-triggers/database-event-triggers.png
.. thumbnail:: /img/graphql/manual/event-triggers/database-event-triggers.png
Event triggers are ideal for use cases such as the following:

4
docs/graphql/manual/deployment/heroku/securing-graphql-endpoint.rst
View File

@ -21,13 +21,13 @@ Add the HASURA_GRAPHQL_ADMIN_SECRET env var
Head to the config-vars URL on your Heroku dashboard and set the ``HASURA_GRAPHQL_ADMIN_SECRET`` environment variable.
.. thumbnail:: ../../../../img/graphql/manual/deployment/secure-heroku.png
.. thumbnail:: /img/graphql/manual/deployment/secure-heroku.png
:alt: Add an admin secret
Setting this environment variable will automatically restart the dyno. Now when you access your console, you'll be
prompted for the admin secret key.
.. thumbnail:: ../../../../img/graphql/manual/deployment/access-key-console.png
.. thumbnail:: /img/graphql/manual/deployment/access-key-console.png
:alt: Prompt for the admin secret
.. note::

4
docs/graphql/manual/deployment/heroku/using-existing-heroku-database.rst
View File

@ -41,7 +41,7 @@ Step 2: Remove the created Postgres add-on in the app
Head to your Heroku dashboard and delete the Postgres add-on created in the previous step:
.. thumbnail:: ../../../../img/graphql/manual/deployment/remove-heroku-postgres-addon.png
.. thumbnail:: /img/graphql/manual/deployment/remove-heroku-postgres-addon.png
:alt: Delete the Postgres add-on
Step 3: Configure environment variables
@ -50,7 +50,7 @@ Step 3: Configure environment variables
Now configure the ``DATABASE_URL`` with your existing Heroku Postgres database URL and a ``HASURA_GRAPHQL_ADMIN_SECRET``
if you want to secure your endpoint.
.. thumbnail:: ../../../../img/graphql/manual/deployment/heroku-database-url-access.png
.. thumbnail:: /img/graphql/manual/deployment/heroku-database-url-access.png
:alt: Configure environment variables
.. note::

2
docs/graphql/manual/deployment/production-checklist.rst
View File

@ -46,7 +46,7 @@ Review the authorization/permission rules set on tables. You can make use of the
permissions set across all tables and roles. Pay extra attention to roles like
"anonymous" which allow unauthenticated access.
.. thumbnail:: ../../../img/graphql/manual/deployment/schema_permissions_summary.png
.. thumbnail:: /img/graphql/manual/deployment/schema_permissions_summary.png
:alt: Hasura console - Schema permissions summary
:width: 75%

4
docs/graphql/manual/event-triggers/create-trigger.rst
View File

@ -17,7 +17,7 @@ Event triggers can be created using the Hasura console or metadata APIs.
Open the Hasura console, head to the ``Events`` tab and click on the ``Create`` button to open the
page below:
.. thumbnail:: ../../../img/graphql/manual/event-triggers/create-event-trigger.png
.. thumbnail:: /img/graphql/manual/event-triggers/create-event-trigger.png
:alt: Create an event trigger
Parameters
@ -44,7 +44,7 @@ before using it for this configuration*).
Advanced Settings
-----------------
.. thumbnail:: ../../../img/graphql/manual/event-triggers/create-event-trigger-advanced-settings.png
.. thumbnail:: /img/graphql/manual/event-triggers/create-event-trigger-advanced-settings.png
:alt: Advanced settings for event triggers
Listen columns for update

2
docs/graphql/manual/event-triggers/index.rst
View File

@ -15,7 +15,7 @@ Event Triggers
Hasura can be used to create event triggers on tables in the Postgres database. Event triggers reliably capture
events on specified tables and invoke webhooks to carry out any custom logic.
.. thumbnail:: ../../../img/graphql/manual/event-triggers/database-event-triggers.png
.. thumbnail:: /img/graphql/manual/event-triggers/database-event-triggers.png
:class: no-shadow
:width: 80%
:alt: Hasura event trigger architecture

4
docs/graphql/manual/event-triggers/invoke-trigger-console.rst
View File

@ -19,12 +19,12 @@ In the ``Data -> [table-name] -> Browse Rows`` tab, clicking the ``invoke trigge
you invoke "manual event triggers" configured on the table with that row as payload *(the button will be shown
only if you have any triggers configured)*:
.. thumbnail:: ../../../img/graphql/manual/event-triggers/select-manual-trigger.png
.. thumbnail:: /img/graphql/manual/event-triggers/select-manual-trigger.png
:alt: Invoke event trigger on console
Click on the event trigger you want to run and a modal will pop up with the request and response.
.. thumbnail:: ../../../img/graphql/manual/event-triggers/run-manual-trigger.png
.. thumbnail:: /img/graphql/manual/event-triggers/run-manual-trigger.png
:alt: Request and response of event trigger
.. note::

6
docs/graphql/manual/getting-started/first-event-trigger.rst
View File

@ -28,7 +28,7 @@ the following columns:
name TEXT
)
.. thumbnail:: ../../../img/graphql/manual/getting-started/create-profile-table.png
.. thumbnail:: /img/graphql/manual/getting-started/create-profile-table.png
:alt: Create a table
Setup an event trigger
@ -40,7 +40,7 @@ In the Hasura console, navigate to ``Events -> Create trigger`` and:
3. Select operations: ``insert``, ``update`` and ``delete``.
4. Enter webhook URL as: ``https://httpbin.org/post``.
.. thumbnail:: ../../../img/graphql/manual/getting-started/create-event-trigger.png
.. thumbnail:: /img/graphql/manual/getting-started/create-event-trigger.png
:alt: Set up an event trigger
This sets up our webhook ``https://httpbin.org/post`` to receive database changes on an insert, update and delete on
@ -54,7 +54,7 @@ Watch the trigger in action
2. Now navigate to the ``Events`` tab and click on the ``echo`` trigger in the left sidebar.
3. Expand the details of an event to see the response from the webhook.
.. thumbnail:: ../../../img/graphql/manual/getting-started/trigger-events.png
.. thumbnail:: /img/graphql/manual/getting-started/trigger-events.png
:alt: Trigger in action
Next steps

4
docs/graphql/manual/getting-started/first-graphql-query.rst
View File

@ -27,7 +27,7 @@ the following columns:
name TEXT
)
.. thumbnail:: ../../../img/graphql/manual/getting-started/create-profile-table.png
.. thumbnail:: /img/graphql/manual/getting-started/create-profile-table.png
:alt: Create a table
Now, insert some sample data into the table using the ``Insert Row`` tab of the ``profile`` table.
@ -48,7 +48,7 @@ Head to the ``GraphiQL`` tab in the console and try running the following query:
You'll see that you get all the inserted data!
.. thumbnail:: ../../../img/graphql/manual/getting-started/profile-query.png
.. thumbnail:: /img/graphql/manual/getting-started/profile-query.png
:alt: Try out a query
Next steps

4
docs/graphql/manual/getting-started/heroku-simple.rst
View File

@ -33,7 +33,7 @@ Click the button below to deploy to Heroku:
If you don't have an account on Heroku, you need to sign up on Heroku. You won't need a credit card, and once you
sign up you'll be redirected to your Heroku app creation page automatically.
.. thumbnail:: ../../../img/graphql/manual/getting-started/heroku-app.png
.. thumbnail:: /img/graphql/manual/getting-started/heroku-app.png
:alt: Deploy to Heroku
Note that **Heroku's free Postgres add-on** is also automatically provisioned!
@ -44,7 +44,7 @@ Open the Hasura console
That's it! Head to ``https://<YOUR_HEROKU_APP>.herokuapp.com`` and open your app.
You should see the Hasura console.
.. thumbnail:: ../../../img/graphql/manual/getting-started/heroku-app-deployed.png
.. thumbnail:: /img/graphql/manual/getting-started/heroku-app-deployed.png
:alt: Open the Hasura console
Hello World (GraphQL or event triggers)

2
docs/graphql/manual/getting-started/index.rst
View File

@ -18,7 +18,7 @@ To use the Hasura GraphQL engine, you need to:
#. Use the Hasura console (an admin UI) that connects to the Hasura GraphQL engine to help you build your schema and
run GraphQL queries
.. thumbnail:: ../../../img/graphql/manual/getting-started/running-hasura.png
.. thumbnail:: /img/graphql/manual/getting-started/running-hasura.png
:width: 75%
:class: no-shadow
:alt: Running Hasura

10
docs/graphql/manual/guides/data-modelling/soft-deletes.rst
View File

@ -24,7 +24,7 @@ there is a timestamp value present, the record should be treated as deleted.
**For example:** Let's imagine that we have a simple Todo application, our ``todos`` table would resemble
the following:
.. thumbnail:: ../../../../img/graphql/manual/guides/soft-deletes-example-data.png
.. thumbnail:: /img/graphql/manual/guides/soft-deletes-example-data.png
:alt: Todo table of a todo application
In this example we only have two todos, one has ``deleted_at`` with a timestamp value and the other contains a
@ -79,17 +79,17 @@ Here are some typical rules we should set:
**Delete permissions** - remove all access
.. thumbnail:: ../../../../img/graphql/manual/guides/soft-deletes-delete-perms.png
.. thumbnail:: /img/graphql/manual/guides/soft-deletes-delete-perms.png
:alt: Delete permissions for role user
**Insert permissions** - remove access for inserting into ``deleted_at`` column
.. thumbnail:: ../../../../img/graphql/manual/guides/soft-deletes-insert-perms.png
.. thumbnail:: /img/graphql/manual/guides/soft-deletes-insert-perms.png
:alt: Insert permissions for role user
**Update permissions** - allow access for updating ``deleted_at`` column
.. thumbnail:: ../../../../img/graphql/manual/guides/soft-deletes-update-perms.png
.. thumbnail:: /img/graphql/manual/guides/soft-deletes-update-perms.png
:alt: Update permissions for role user
Step 4: Restrict access to soft-deleted records
@ -103,7 +103,7 @@ access to the ``todos`` table.
For example, let's say that a role ``user`` can only access non-deleted todos, we need to add the following
permission rule to ensure this:
.. thumbnail:: ../../../../img/graphql/manual/guides/soft-deletes-select-perms.png
.. thumbnail:: /img/graphql/manual/guides/soft-deletes-select-perms.png
:alt: Restrict access to soft-deleted records
Now the role ``user`` can only access non-deleted ``todos``:

4
docs/graphql/manual/guides/deployment/render-one-click.rst
View File

@ -31,7 +31,7 @@ new managed PostgreSQL database wired up to your Hasura instance.
You will see the Hasura web service and PostgreSQL instance to be created:
.. thumbnail:: ../../../../img/graphql/manual/deployment/deploy-to-render-hasura-iac.png
.. thumbnail:: /img/graphql/manual/deployment/deploy-to-render-hasura-iac.png
:alt: Deploy To Render Hasura Page
That's it! Read on to configure your Hasura instance.
@ -41,7 +41,7 @@ Access your Hasura Console
Once **Deploy to Render** succeeds, you can click through to your Hasura service page on Render's dashboard.
.. thumbnail:: ../../../../img/graphql/manual/deployment/deploy-to-render-hasura-header.png
.. thumbnail:: /img/graphql/manual/deployment/deploy-to-render-hasura-header.png
:alt: Render Hasura Header
You can monitor the deployment of the Hasura web service from the **Logs** tab. Once the service is up, use the link on the service page to access your Hasura console:

14
docs/graphql/manual/guides/integrations/auth-guardian-jwt.rst
View File

@ -61,7 +61,7 @@ Let's say you're using GitHub as the primary login for your Hasura app, and that
- Add set the user id in the "built-in value" field to ``GITHUB_USER_ID``
- Click the ``save`` button on the right hand side.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-user-id.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-user-id.png
:alt: Set an AuthGuardian JWT with a user id
Option 2: Set the default Hasura role
@ -75,7 +75,7 @@ Add a new rule (the ``+`` button in the top-left), and fill it out:
- Add the default role, e.g. ``user``.
- Click the ``save`` button on the right hand side.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-default-role.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-default-role.png
:alt: Set an AuthGuardian JWT with default role
.. note::
@ -91,7 +91,7 @@ Now, you want to restrict access to some data in Hasura so that only you and you
- Click on "Add" and add an additional role, e.g. ``admin``.
- Click the ``save`` button on the right hand side.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-additional-role.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-additional-role.png
:alt: Set an AuthGuardian JWT with additional roles
Option 4: Set a session variable
@ -105,7 +105,7 @@ Let's say we want to restrict access to some super-interesting data in our Hasur
- Add your session variable name ``is-our-biggest-fan`` and value to JSON ``true``.
- Click the ``save`` button on the right hand side.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-session-variable.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-session-variable.png
:alt: Set an AuthGuardian JWT with session variables for Hasura to use
.. note::
@ -140,7 +140,7 @@ The generated config has the following structure:
- Add the generated config as a value for the environment variable ``HASURA_GRAPHQL_JWT_SECRET`` or for the ``--jwt-secret`` server flag.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-config-generator.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-config-generator.png
:alt: AuthGuardian lets you copy/paste the required JWT configuration for either Hasura or Hasura-on-Heroku
Step 4: Test the config and tokens
@ -152,12 +152,12 @@ When configuring your permissions in Hasura, it's useful to be able to quickly g
- Paste the copied JWT (or optionally write your own JSON if you want to test alternative scenarios).
- Copy the signed token and add it as a header in the Hasura console.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-generate-test-jwt.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-generate-test-jwt.png
:alt: Use the JWT-signer form to quickly sign any JSON and test in the Hasura console
- In GraphiQL, try out queries to test that the integration works as expected by adding an ``Authorization`` header, with a value of ``Bearer <the-copied-JWT-text>``. Hasura's GraphiQL will recognize this header, show you its content, and confirm whether it recognizes the JWT as securely signed.
.. thumbnail:: ../../../../img/graphql/manual/guides/auth-guardian-test-jwt.png
.. thumbnail:: /img/graphql/manual/guides/auth-guardian-test-jwt.png
:alt: Test AuthGuardian JWT
Next Steps

4
docs/graphql/manual/guides/integrations/auth0-jwt.rst
View File

@ -22,7 +22,7 @@ Create an Auth0 Application
- In the ``Create Application`` window, set a name for your application and select ``Single Page Web Applications``
(assuming your application is React/Angular/Vue etc).
.. thumbnail:: ../../../../img/graphql/manual/guides/create-client-popup.png
.. thumbnail:: /img/graphql/manual/guides/create-client-popup.png
:alt: Create an Auth0 application
Configure Auth0 Rules & Callback URLs
@ -189,7 +189,7 @@ The generated config can be used in env ``HASURA_GRAPHQL_JWT_SECRET`` or ``--jwt
The config generated from this page can be directly pasted in ``yaml`` files and command line arguments as it takes care of
escaping new lines.
.. thumbnail:: ../../../../img/graphql/manual/auth/jwt-config-generated.png
.. thumbnail:: /img/graphql/manual/auth/jwt-config-generated.png
:width: 75%
:alt: Generated JWT config

6
docs/graphql/manual/how-it-works/metadata-schema.rst
View File

@ -40,7 +40,7 @@ the metadata API.
Schema
""""""
.. thumbnail:: ../../../img/graphql/manual/engine-internals/hdb_table.jpg
.. thumbnail:: /img/graphql/manual/engine-internals/hdb_table.jpg
:width: 30%
:alt: hdb_table schema
@ -66,7 +66,7 @@ the metadata API.
Schema
""""""
.. thumbnail:: ../../../img/graphql/manual/engine-internals/hdb_relationship.jpg
.. thumbnail:: /img/graphql/manual/engine-internals/hdb_relationship.jpg
:width: 30%
:alt: hdb_relationship schema
@ -110,7 +110,7 @@ the metadata API.
Schema
""""""
.. thumbnail:: ../../../img/graphql/manual/engine-internals/hdb_permission.jpg
.. thumbnail:: /img/graphql/manual/engine-internals/hdb_permission.jpg
:width: 30%
:alt: hdb_permission schema

4
docs/graphql/manual/remote-schemas/index.rst
View File

@ -23,7 +23,7 @@ endpoint to Hasura. Your GraphQL service can be written in any language or frame
This is what Hasura running with "Remote schemas" looks like:
.. thumbnail:: ../../../img/graphql/manual/remote-schemas/remote-schemas-arch.png
.. thumbnail:: /img/graphql/manual/remote-schemas/remote-schemas-arch.png
:class: no-shadow
:width: 55%
:alt: Architecture of Hasura with remote schemas
@ -76,7 +76,7 @@ To merge your remote schema with the GraphQL engine's auto-generated schema:
Head to the ``Remote Schemas`` tab of the console and click on the ``Add`` button.
.. thumbnail:: ../../../img/graphql/manual/business-logic/add-remote-schemas-interface.png
.. thumbnail:: /img/graphql/manual/business-logic/add-remote-schemas-interface.png
:alt: Merge remote schema
You need to enter the following information:

2
docs/graphql/manual/schema/basics.rst
View File

@ -48,7 +48,7 @@ automatically generated.
For example, here is the schema for the ``article`` table in this interface:
.. thumbnail:: ../../../img/graphql/manual/schema/create-table-graphql.png
.. thumbnail:: /img/graphql/manual/schema/create-table-graphql.png
:alt: Schema for an article table
The following object type and query/mutation fields are generated for the ``article`` table we just created:

2
docs/graphql/manual/schema/computed-fields.rst
View File

@ -173,7 +173,7 @@ Adding a computed field to a table
Head to the ``Modify`` tab of the table and click on the ``Add`` button in the ``Computed fields``
section:
.. thumbnail:: ../../../img/graphql/manual/schema/computed-field-create.png
.. thumbnail:: /img/graphql/manual/schema/computed-field-create.png
.. admonition:: Supported from

4
docs/graphql/manual/schema/custom-field-names.rst
View File

@ -28,7 +28,7 @@ Expose columns with a different name in the GraphQL API
Head to the ``Data -> [table-name] -> Modify``
.. thumbnail:: ../../../img/graphql/manual/schema/custom-field-name-column.png
.. thumbnail:: /img/graphql/manual/schema/custom-field-name-column.png
:alt: Customise GraphQL field name
.. tab:: Metadata API
@ -50,7 +50,7 @@ Expose table root fields with a different name in the GraphQL API
Head to the ``Data -> [table-name] -> Modify``
.. thumbnail:: ../../../img/graphql/manual/schema/custom-field-name-root-fields.png
.. thumbnail:: /img/graphql/manual/schema/custom-field-name-root-fields.png
:alt: Customise GraphQL root field
.. tab:: Metadata API

10
docs/graphql/manual/schema/data-validations.rst
View File

@ -51,7 +51,7 @@ Let's say we have a table:
Now, we can head to the ``Modify`` tab in the table page and add a check
constraint in the ``Check Constraints`` section:
.. thumbnail:: ../../../img/graphql/manual/schema/validation-add-check-constraint.png
.. thumbnail:: /img/graphql/manual/schema/validation-add-check-constraint.png
:alt: Add check constraint
If someone now tries to add an author with a rating of ``11``, the following
@ -185,7 +185,7 @@ Suppose, we have a table:
Now, we can create a role ``user`` and add the following rule:
.. thumbnail:: ../../../img/graphql/manual/schema/validation-not-empty.png
.. thumbnail:: /img/graphql/manual/schema/validation-not-empty.png
:alt: validation using permission: title cannot be empty
If we try to insert an article with ``title = ""``, we will get a ``permission-error``:
@ -233,7 +233,7 @@ Also, suppose there is an :ref:`object relationship <graphql_relationships>` ``a
Now, we can create a role ``user`` and add the following rule:
.. thumbnail:: ../../../img/graphql/manual/schema/validation-author-isactive.png
.. thumbnail:: /img/graphql/manual/schema/validation-author-isactive.png
:alt: validation using permissions: author should be active
If we try to insert an article for an author for whom ``is_active = false``, we
@ -291,7 +291,7 @@ or not.
The validation process looks as follows:
.. thumbnail:: ../../../img/graphql/manual/schema/actions-data-validation.png
.. thumbnail:: /img/graphql/manual/schema/actions-data-validation.png
:alt: validation using actions: article not blacklisted
:width: 60%
@ -301,7 +301,7 @@ Actions allow us to define :ref:`custom types <custom_types>` in our GraphQL sch
We create a new action called ``InsertAuthor`` that takes an ``author`` object with type ``AuthorInput`` as input and
returns an object of type ``AuthorOutput``:
.. thumbnail:: ../../../img/graphql/manual/schema/validation-actions-def.png
.. thumbnail:: /img/graphql/manual/schema/validation-actions-def.png
:alt: Create action
The business logic of an action - in our case the author validation - happens in the :ref:`action handler <action_handlers>`

8
docs/graphql/manual/schema/default-values/column-presets.rst
View File

@ -32,13 +32,13 @@ Step 1: Configure a column preset
The column preset option is available under the ``Permissions`` tab of a table. Open the console and head to
``Data -> article -> Permissions``:
.. thumbnail:: ../../../../img/graphql/manual/schema/column-presets-option.png
.. thumbnail:: /img/graphql/manual/schema/column-presets-option.png
:alt: Add a column preset in the permissions tab
Enable the column preset option to define presets for one or more columns. For each column, you can pick between
setting the preset using a static value or from a session variable.
.. thumbnail:: ../../../../img/graphql/manual/schema/column-presets-value-options.png
.. thumbnail:: /img/graphql/manual/schema/column-presets-value-options.png
:alt: Configure the column preset
For our chosen example, we'll use the ``from session variable`` option and configure the ``user_id`` column to be
@ -62,13 +62,13 @@ to select from the* ``article`` *table*):
As mentioned earlier, you'll notice when you add the ``X-Hasura-Role`` header that the field, ``user_id``, is no longer
available as the mutation type's field:
.. thumbnail:: ../../../../img/graphql/manual/schema/column-preset-schema-change-for-role.png
.. thumbnail:: /img/graphql/manual/schema/column-preset-schema-change-for-role.png
:alt: Write an insert mutation
Now, if we run the following insert mutation, we'll see that the ``user_id`` field is indeed being set with the value
passed in the ``X-Hasura-User-Id`` variable:
.. thumbnail:: ../../../../img/graphql/manual/schema/column-preset-mutation-result.png
.. thumbnail:: /img/graphql/manual/schema/column-preset-mutation-result.png
:alt: Run the insert mutation
.. note::

4
docs/graphql/manual/schema/default-values/postgres-defaults.rst
View File

@ -30,7 +30,7 @@ Edit the ``created_at`` field and set its default value as the SQL function ``no
Open the console and head to ``Data -> article -> Modify``:
.. thumbnail:: ../../../../img/graphql/manual/schema/add-default-value.png
.. thumbnail:: /img/graphql/manual/schema/add-default-value.png
:alt: Modify the table in the console
.. admonition:: To set an auto-incrementing default value
@ -56,7 +56,7 @@ Step 2: Run an insert mutation
Now if you do not pass the ``created_at`` field value while running an insert mutation on the ``article`` table, its
value will be set automatically by Postgres.
.. thumbnail:: ../../../../img/graphql/manual/schema/default-value-response.png
.. thumbnail:: /img/graphql/manual/schema/default-value-response.png
:alt: Run an insert mutation
Also see

4
docs/graphql/manual/schema/default-values/sql-functions.rst
View File

@ -39,7 +39,7 @@ Modify the table ``sql_function_table`` and make its ``output`` column nullable.
Open the console and head to ``Data -> sql_function_table -> Modify``:
.. thumbnail:: ../../../../img/graphql/manual/schema/modify-sql-fn-table.png
.. thumbnail:: /img/graphql/manual/schema/modify-sql-fn-table.png
:alt: Modify the table
Step 2: Create a trigger
@ -62,7 +62,7 @@ the ``output`` field whenever an insert or update is made to the ``sql_function_
Head to ``Data -> SQL`` and run the above SQL:
.. thumbnail:: ../../../../img/graphql/manual/schema/create-trigger.png
.. thumbnail:: /img/graphql/manual/schema/create-trigger.png
:alt: Create a trigger with SQL
Step 3: Run an insert mutation

2
docs/graphql/manual/schema/enums.rst
View File

@ -144,7 +144,7 @@ we need to tell Hasura that this table represents an enum.
Head to the ``Modify`` tab of the table and toggle the switch in the
``Set table as enum`` section:
.. thumbnail:: ../../../img/graphql/manual/schema/enum-set.png
.. thumbnail:: /img/graphql/manual/schema/enum-set.png
:alt: Set table as enum
.. tab:: API

10
docs/graphql/manual/schema/relationships/create.rst
View File

@ -35,7 +35,7 @@ In the console, navigate to the ``Modify`` tab of the ``article`` table. Click t
the Foreign Keys section and configure the ``author_id`` column as a foreign-key for the ``id`` column in
the ``author`` table:
.. thumbnail:: ../../../../img/graphql/manual/schema/add-foreign-key.png
.. thumbnail:: /img/graphql/manual/schema/add-foreign-key.png
:alt: Add foreign-key constraint
Step 2: Create an object relationship
@ -48,7 +48,7 @@ The console infers this using the foreign-key created above and recommends the p
Add an ``object relationship`` named ``author`` for the ``article`` table as shown here:
.. thumbnail:: ../../../../img/graphql/manual/schema/add-1-1-relationship.png
.. thumbnail:: /img/graphql/manual/schema/add-1-1-relationship.png
:alt: Create an object relationship
We can now run a nested object query that is based on this ``object relationship``.
@ -109,7 +109,7 @@ You can add an ``array relationship`` in the same fashion as an ``object relatio
Add an ``array relationship`` named ``articles`` for the ``author`` table as shown here:
.. thumbnail:: ../../../../img/graphql/manual/schema/add-1-many-relationship.png
.. thumbnail:: /img/graphql/manual/schema/add-1-many-relationship.png
:alt: Create an array relationship
We can now run a nested object query that is based on this ``array relationship``.
@ -200,7 +200,7 @@ Step 1: Open the manual relationship section
- Open the console and navigate to the ``Data -> author -> Relationships`` tab.
- Click on the ``Configure`` button:
.. thumbnail:: ../../../../img/graphql/manual/schema/manual-relationship-btn.png
.. thumbnail:: /img/graphql/manual/schema/manual-relationship-btn.png
:alt: Open the manual relationship section
Step 2: Define the relationship
@ -208,7 +208,7 @@ Step 2: Define the relationship
The above step will open up a section as shown below:
.. thumbnail:: ../../../../img/graphql/manual/schema/manual-relationship-create.png
.. thumbnail:: /img/graphql/manual/schema/manual-relationship-create.png
:alt: Define the relationship
In this case:

2
docs/graphql/manual/troubleshooting/index.rst
View File

@ -67,7 +67,7 @@ which is used while fetching nested objects using GraphQL.
Let's say we have tables called ``article`` and ``author`` as follows:
.. thumbnail:: ../../../img/graphql/manual/troubleshooting/author_article.jpg
.. thumbnail:: /img/graphql/manual/troubleshooting/author_article.jpg
:alt: article author schema
Using the console if you have created a relationship named ``author`` from the ``article`` table to