-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(auth): allow non-interactive grants for incoming payments #588
Conversation
Q: Should we have the same behavior for quote grant requests? @wilsonianb |
I'm not sure. |
packages/auth/src/grant/routes.ts
Outdated
@@ -66,7 +71,8 @@ export function createGrantRoutes({ | |||
} | |||
} | |||
|
|||
function validateGrantRequest( | |||
// exported for testing | |||
export function validateGrantRequest( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this have checks that aren't covered by the OpenAPI validator middleware?
rafiki/packages/auth/src/app.ts
Line 239 in 0642a0f
createValidatorMiddleware<ContextType<typeof route>>(openApi, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so but I'd like @njlie to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're missing out on the benefits of the OpenAPI validator middleware type guard by not specifying the ctx.body
type in createGrantInitiation
and elsewhere
rafiki/packages/openapi/src/index.ts
Lines 47 to 51 in 668e7cb
export type ValidateFunction<T> = (data: any) => data is T | |
export interface OpenAPI { | |
paths: Paths | |
createRequestValidator<T>(options: RequestOptions): ValidateFunction<T> |
See:
rafiki/packages/backend/src/open_payments/payment/incoming/routes.ts
Lines 79 to 88 in 668e7cb
export type CreateBody = { | |
description?: string | |
expiresAt?: string | |
incomingAmount?: AmountJSON | |
externalRef?: string | |
} | |
async function createIncomingPayment( | |
deps: ServiceDependencies, | |
ctx: CreateContext<CreateBody> |
- Maybe reopen Validate GNAP requests with OpenAPI #351 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd hold off on any work there now that Adrian has been working on his auth server implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so but I'd like @njlie to confirm.
Yeah I'm pretty sure this can be excised now, I wrote this before we had brought OpenAPI into the auth service. This basically is a type guard against the POST /
request which is definitely covered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the validation function and re-opened #351
Then let's leave it as is for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should
config.authServerSpec
be updated to include feat(auth-spec): grant request changes open-payments#168 ?
@@ -10,6 +10,10 @@ function envInt(name: string, value: number): number { | |||
return envValue == null ? value : parseInt(envValue) | |||
} | |||
|
|||
function envBool(name: string, value: boolean): boolean { | |||
const envValue = process.env[name] | |||
return envValue == null ? value : envValue === 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer your version over:
rafiki/packages/backend/src/config/app.ts
Lines 20 to 23 in 668e7cb
// function envBool(name: string, value: boolean): boolean { | |
// const envValue = process.env[name] | |
// return envValue == null ? value : Boolean(envValue) | |
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know we had that.
packages/auth/src/grant/routes.ts
Outdated
@@ -66,7 +71,8 @@ export function createGrantRoutes({ | |||
} | |||
} | |||
|
|||
function validateGrantRequest( | |||
// exported for testing | |||
export function validateGrantRequest( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're missing out on the benefits of the OpenAPI validator middleware type guard by not specifying the ctx.body
type in createGrantInitiation
and elsewhere
rafiki/packages/openapi/src/index.ts
Lines 47 to 51 in 668e7cb
export type ValidateFunction<T> = (data: any) => data is T | |
export interface OpenAPI { | |
paths: Paths | |
createRequestValidator<T>(options: RequestOptions): ValidateFunction<T> |
See:
rafiki/packages/backend/src/open_payments/payment/incoming/routes.ts
Lines 79 to 88 in 668e7cb
export type CreateBody = { | |
description?: string | |
expiresAt?: string | |
incomingAmount?: AmountJSON | |
externalRef?: string | |
} | |
async function createIncomingPayment( | |
deps: ServiceDependencies, | |
ctx: CreateContext<CreateBody> |
- Maybe reopen Validate GNAP requests with OpenAPI #351 ?
!deps.config.incomingPaymentInteraction && | ||
body.access_token.access | ||
.map((acc) => { | ||
return isIncomingPaymentAccessRequest(acc as IncomingPaymentRequest) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return isIncomingPaymentAccessRequest(acc as IncomingPaymentRequest) | |
return isIncomingPaymentAccessRequest(acc as AccessRequest) |
I think the isIncomingPaymentAccessRequest
argument type should be changed to AccessRequest
.
Also, if we specified ctx.body
type we wouldn't need to cast here at all (#588 (comment))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bump
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want to touch this because I thought I would add the change to have the ctx.body
typed but that's probably going to be a subsequent PR so yes, I'll change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it complains with
Types of property 'type' are incompatible.
Type 'AccessType.OutgoingPayment' is not assignable to type 'AccessType.IncomingPayment'.ts(2345)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BaseAccessRequest
might work, but I just noticed the other type guards also have the target type as the argument type.
Maybe they can all be updated as part of #351 instead of this pr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is a good idea.
table.string('continueToken').unique() | ||
table.string('continueId').unique() | ||
table.string('continueToken').notNullable().unique() | ||
table.string('continueId').notNullable().unique() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't be necessary to generate continuation information if interaction (or further continuation) isn't necessary for a grant. The POST /
should just return the access token without any continuation information. Continuation information could just be generated if the grant is modified in a way that requires interaction to be issued again (if we end up supporting that again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we discussed that while you were away. We always want to be able to delete/revoke the grant and for that you need the continue token and id. Hence, it must always be present. We also already changed the spec to make it always required.
packages/auth/src/grant/routes.ts
Outdated
access: access.map((a: Access) => accessToBody(a)), | ||
expiresIn: accessToken.expiresIn | ||
expiresIn: accessToken.expiresIn, | ||
continue: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can exclude the continue
object if there's no interaction required and the AS can just supply an access_token
instead. Also vice/versa for if interaction is required. It's basically an either/or situation between continue
and access_token
with how we're using GNAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above.
!deps.config.incomingPaymentInteraction && | ||
body.access_token.access | ||
.map((acc) => { | ||
return isIncomingPaymentAccessRequest(acc as IncomingPaymentRequest) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bump
access_token: { | ||
value: grant.continueToken | ||
}, | ||
uri: domain + `continue/${grant.continueId}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this still include wait
(RECOMMENDED
)?
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#section-3.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so because the grant is granted right away. At least that was my interpretation of it.
Changes proposed in this pull request
incoming-payment
, the grant will be issued right away, without interactionContext
Checklist
fixes #number