Hasura v1.3.3 Release Notes

Release Date: 2020-11-17 // over 3 years ago
  • 0️⃣ Server - Support for mapping session variables to default JWT claims

    πŸ”§ Some auth providers do not let users add custom claims in JWT. In such cases, the server can take a JWT configuration option called claims_map to specify a mapping of Hasura session variables to values in existing claims via JSONPath or literal values.

    Example:-

    Consider the following JWT claim:

      {
        "sub": "1234567890",
        "name": "John Doe",
        "admin": true,
        "iat": 1516239022,
        "user": {
          "id": "ujdh739kd",
          "appRoles": ["user", "editor"]
        }
      }
    

    The corresponding JWT config can be:

      {
        "type":"RS512",
        "key": "<The public Key>",
        "claims_map": {
          "x-hasura-allowed-roles": {"path":"$.user.appRoles"},
          "x-hasura-default-role": {"path":"$.user.appRoles[0]","default":"user"},
          "x-hasura-user-id": {"path":"$.user.id"}
        }
      }
    

    πŸ“‡ Metadata Types SDK

    πŸ“š The types and documentation comments for Metadata V2 have been converted into JSON/YAML Schema, and used to autogenerate type definitions for popular languages.

    πŸ“‡ This enables users to build type-safe tooling in the language of their choice around Metadata interactions and automations.

    βž• Additionally, the JSON/YAML Schemas can be used to provide IntelliSense and autocomplete + documentation when interacting with Metadata YAML/JSON files.

    πŸ“‡ For a more comprehensive overview, please see [the readme located here](./contrib/metadata-types/README.md)

    Sample Code

    import { TableEntry } from "../generated/HasuraMetadataV2";
    
    const newTable: TableEntry = {
      table: { schema: "public", name: "user" },
      select_permissions: [
        {
          role: "user",
          permission: {
            limit: 100,
            allow_aggregations: false,
            columns: ["id", "name", "etc"],
            computed_fields: ["my_computed_field"],
            filter: {
              id: { _eq: "X-Hasura-User-ID" },
            },
          },
        },
      ],
    };
    

    IntelliSense Example

    πŸ“‡ [](./contrib/metadata-types/json-schema-typecheck-demo.gif)

    πŸ’₯ Breaking changes

    PDV

    πŸš€ This release contains the PDV refactor (#4111), a significant rewrite of the internals of the server, which did include some breaking changes:

    • πŸ‘‰ The semantics of explicit null values in where filters have changed according to the discussion in issue 704: an explicit null value in a comparison input object will be treated as an error rather than resulting in the expression being evaluated to True. For instance: delete_users(where: {id: {_eq: $userId}}) { name } will yield an error if $userId is null instead of deleting all users.
    • πŸ›  The validation of required headers has been fixed (closing #14 and #3659):
      • if a query selects table bar through table foo via a relationship, the required permissions headers will be the union of the required headers of table foo and table bar (we used to only check the headers of the root table);
      • if an insert does not have an on_conflict clause, it will not require the update permissions headers.

    Remote Relationship

    πŸš€ In this release, a breaking change has been introduced:

    In a remote relationship query, the remote schema will be queried when all of the joining arguments are not null values. When there are null value(s), the remote schema won't be queried and the response of the remote relationship field will be null. Earlier, the remote schema was queried with the null value arguments and the response depended upon how the remote schema handled the null arguments.

    πŸ› Bug fixes and improvements

    πŸ“„ (Add entries here in the order of: server, console, cli, docs, others)

    • πŸ›  server: allow remote relationships joining type column with [type] input argument as spec allows this coercion (fixes #5133)
    • πŸ›  server: add action-like URL templating for event triggers and remote schemas (fixes #2483)
    • ⏱ server: change created_at column type from timestamp to timestamptz for scheduled triggers tables (fix #5722)
    • πŸ”§ server: allow configuring timeouts for actions (fixes #4966)
    • server: fix bug which arised when renaming a table which had a manual relationship defined (close #4158)
    • server: limit the length of event trigger names (close #5786) NOTE: If you have event triggers with names greater than 42 chars, then you should update their names to avoid running into Postgres identifier limit bug (#5786)
    • server: enable HASURA_GRAPHQL_PG_CONN_LIFETIME by default to reclaim memory
    • server: fix issue with tracking custom functions that return SETOF materialized view (close #5294) (#5945)
    • πŸ›  server: allow remote relationships with union, interface and enum type fields as well (fixes #5875) (#6080)
    • server: Fix fine-grained incremental cache invalidation (fix #6027) This issue could cause enum table values to sometimes not be properly reloaded without restarting graphql-engine. Now a reload_metadata API call (or clicking β€œReload enum values” in the console) should consistently force a reload of all enum table values.
    • πŸ“‡ server: fix event trigger cleanup on deletion via replace_metadata (fix #5461) (#6137) WARNING: This can cause significant load on PG on startup if you have lots of event triggers. Delay in starting up is expected.
    • console: add notifications (#5070)
    • πŸ“‡ cli: fix bug in metadata apply which made the server aquire some redundant and unnecessary locks (close #6115)
    • cli: fix cli-migrations-v2 image failing to run as a non root user (close #4651, close #5333)
    • βœ… cli: fix issue with cli binary on latest Mac (Big Sur) (fix #5462)
    • πŸ“„ docs: add docs page on networking with docker (close #4346) (#4811)
    • πŸ“„ docs: add tabs for console / cli / api workflows (close #3593) (#4948)
    • πŸ“„ docs: add postgres concepts page to docs (close #4440) (#4471)
    • πŸ“„ docs: add guides on connecting hasura cloud to pg databases of different cloud vendors (#5948)