feat: fetch entity statement #6
Conversation
Signed-off-by: Berend Sliedrecht <sliedrecht@berend.io>
| @@ -6,4 +6,8 @@ export const entityConfigurationClaimsSchema = entityStatementClaimsSchema.refin | |||
| path: ['iss', 'sub'], | |||
| }) | |||
|
|
|||
| export type EntityConfigurationClaims = z.input<typeof entityConfigurationClaimsSchema> | |||
| type EntityConfigurationClaimsInput = z.input<typeof entityConfigurationClaimsSchema> | |||
There was a problem hiding this comment.
Not entirely sure how we should deal with the types.
our input != output and that complicates things a lot. Maybe we should not do any transformation on the validated items?
There was a problem hiding this comment.
I think we need to use output as the general type we pass around. And the input type in the public layer of the library.
So that we start with transformations of input to output, and then can use the output type as stable type
berendsliedrecht
force-pushed
the
fetch-entity-statement
branch
from
f729a67
to
2e6050f
Compare
| @@ -27,7 +27,7 @@ describe('create entity configuration', () => { | |||
|
|
|||
| it('should create a more complex entity configuration', async () => { | |||
| const entityConfiguration = await createEntityConfiguration({ | |||
| signCallback, | |||
| signJwtCallback: signJwtCallback, | |||
There was a problem hiding this comment.
Not needed to pass twice right (applies to multiple places)
| @@ -6,4 +6,8 @@ export const entityConfigurationClaimsSchema = entityStatementClaimsSchema.refin | |||
| path: ['iss', 'sub'], | |||
| }) | |||
|
|
|||
| export type EntityConfigurationClaims = z.input<typeof entityConfigurationClaimsSchema> | |||
| type EntityConfigurationClaimsInput = z.input<typeof entityConfigurationClaimsSchema> | |||
There was a problem hiding this comment.
I think we need to use output as the general type we pass around. And the input type in the public layer of the library.
So that we start with transformations of input to output, and then can use the output type as stable type
| const claims = { | ||
| iss, | ||
| sub: iss, | ||
| exp: new Date(), |
There was a problem hiding this comment.
Does it also support number as input?
|
|
||
| type EntityConfigurationClaimsOutput = z.output<typeof entityConfigurationClaimsSchema> | ||
|
|
||
| export type EntityConfigurationClaims = EntityConfigurationClaimsInput | EntityConfigurationClaimsOutput |
There was a problem hiding this comment.
I wouldn't type it like this, as it's weird to use this type. We can't easily detect whether we have input or output, so this will complicate things.
You either expect the output type (transformed) or the input type (which is unvalidated/not parsed and will have to go through zod before using)
|
|
||
| throw e | ||
| } | ||
| await verifyJsonWebToken({ jwt: entityConfigurationJwt, verifyJwtCallback }) |
There was a problem hiding this comment.
In some places you use verifyJwtCallback, but here you spell jwt as JsonWebToken
| entityStatementClaimsSchema.parse(claims) | ||
| entityStatementHeaderSchema.parse(header) |
There was a problem hiding this comment.
In the case some transformation is done, i think we should use the return value of this
There was a problem hiding this comment.
Also good to wrap this with error handling so the error message has the right context.
I think an util where you pass data + scheme + additional error message could work.
This could then also throw a custom error type in the future
| @@ -11,3 +11,5 @@ export const entityStatementHeaderSchema = z | |||
| typ: z.literal('entity-statement+jwt'), | |||
| }) | |||
| .passthrough() | |||
|
|
|||
| export type EntityStatementHeader = z.input<typeof entityStatementHeaderSchema> | |||
There was a problem hiding this comment.
Here we should probably call this EntityStatementHeaderOptions or EntityStatementHeaderInput
| @@ -0,0 +1,35 @@ | |||
| import { Buffer } from 'node:buffer' | |||
There was a problem hiding this comment.
Should not depend on node:buffer
| throw new Error('Signature in the JWT is invalid') | ||
| } | ||
| } catch (e: unknown) { | ||
| if (typeof e === 'string') { |
There was a problem hiding this comment.
Should probably also handle error not being instanceof error, so we can assume when calling this library that always an error will be thrown, even if the callback didn't throw an error instance
Signed-off-by: Berend Sliedrecht <sliedrecht@berend.io>
berendsliedrecht
force-pushed
the
fetch-entity-statement
branch
from
2e6050f
to
291505f
Compare
Signed-off-by: Berend Sliedrecht sliedrecht@berend.io