Parse for Hasura vs PromptQL Language #118
Conversation
- Changed `disableSwitch` from true to false to allow users to toggle between light and dark modes. - Added `respectPrefersColorScheme` to ensure the theme respects the user's system color scheme preference.
## Description 📝 Bring back the kitchen sink page ## Quick Links 🚀 [Kitchen Sink](https://sean-doc-2820-bring-back-the.promptql-docs.pages.dev/kitchen-sink/)
|
@seanparkross Thanks for your PR! I've assigned @robertjdominguez to review it. |
Deploying promptql-docs with
|
| Latest commit: |
d90ecd7
|
| Status: | 🚫 Build failed. |
| @@ -19,7 +19,7 @@ keywords: | |||
|
|
|||
| # JWT Mode | |||
|
|
|||
| In JWT mode, session variables are passed to the Hasura Engine on each request in JSON Web Tokens (JWTs). | |||
| In JWT mode, session variables are passed to the engine on each request in JSON Web Tokens (JWTs). | |||
There was a problem hiding this comment.
Without more context from the page, my advice here is to be a bit more abstract:
| In JWT mode, session variables are passed to the engine on each request in JSON Web Tokens (JWTs). | |
| In JWT mode, session variables are passed to your application on each request in JSON Web Tokens (JWTs). |
There was a problem hiding this comment.
I think this is too abstract as it doesn't have enough useful meaning.
| @@ -324,8 +324,8 @@ Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWI... | |||
|
|
|||
| #### Cookie | |||
|
|
|||
| In the cookie mode, Hasura will try to parse the cookie header with the given cookie name. The value of the cookie | |||
| should be the exact JWT. | |||
| In the cookie mode, the DDN engine will try to parse the cookie header with the given cookie name. The value of the | |||
There was a problem hiding this comment.
Why would we make this different from the previous change on line 312?
In this mode, the engine expects an `Authorization` header with a `Bearer` token.
| @@ -88,7 +88,7 @@ AuthConfig. Using `claims.jwt.hasura.io` will match our examples. | |||
| 3. Add any other optional `x-hasura-*` claim fields (required as per your defined permissions) to the custom namespace. | |||
|
|
|||
| To summarize, `x-hasura-allowed-roles` session variable contains a list of all the roles that the user can assume and | |||
| the `x-hasura-role` header tells the Hasura Engine which role to use for the request, and if that is missing then the | |||
| the `x-hasura-role` header tells the engine which role to use for the request, and if that is missing then the | |||
There was a problem hiding this comment.
Similar to what we said earlier, in this context, I think we replaced Hasura engine with API. Why?
In context, we're referring to the behavior of the interface that receives and processes requests (the engine), which is equivalent to an API server.
There was a problem hiding this comment.
This also isn't "correct enough" in my view. It isn't the API, (which is the endpoints, protocol and format) - it's the engine which uses them.
| @@ -193,8 +193,8 @@ If `claimsFormat` is `StringifiedJson` then the JWT claims should look like: | |||
|
|
|||
| #### locations {#jwt-claims-config-locations} | |||
|
|
|||
| This `locations` option can be used when Hasura claims are not all present in the single object, but individual claims | |||
| are provided a JSON pointer within the decoded JWT. In this option, you can indicate: | |||
| This `locations` option can be used when DDN claims are not all present in the single object, but individual claims are | |||
There was a problem hiding this comment.
Earlier, we called this PromptQL claims (line 143).
There was a problem hiding this comment.
🤷♂️ Dunno on this one.
WIP
Quick Links 🚀
Assertion Tests 🤖