chore(backend): replace GrantReference with OutgoingPaymentGrant #800

wilsonianb · 2022-11-30T00:45:44Z

Changes proposed in this pull request

Remove grant references table
Store clientId directly on payment pointer subresources
Add outgoing payment grants for locking while validating grant limits on outgoing payment creation

Context

feat(backend): request grant to query incoming payment receiver #779 (comment)
should help reduce the footprint of Return client payment pointer in introspection response #737

Checklist

Related issues linked using fixes #number
Tests added/updated
Documentation added
Make sure that all checks pass

sabineschaller

Makes sense to me. Thank you!

wilsonianb · 2022-11-30T15:32:45Z

🤔 Would we still want to be able to link resources with the corresponding grants used to create them, for auditing or some other purpose?
I was just looking at section 2.1.3 of https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf which seems to actually recommend that the RS would store the grant permissions (or perhaps just keep things as is with GrantReference since our AS is currently bound to the RS)

mkurapov · 2022-11-30T19:38:30Z

@wilsonianb It feels like the "RTP" is more of a general concept in this case right? i.e. RTP != RS?

In general, having more information about the grant would be a good thing IMO, could do further checks other than the clientId, for example...

mkurapov

Left a few comments, but wouldn't mind going the other way and expanding the info stored in the og grantreference table

mkurapov · 2022-11-30T17:35:09Z

packages/backend/src/open_payments/quote/routes.ts

@@ -60,7 +60,7 @@ async function createQuote(
      receiver: body.receiver,
      sendAmount: body.sendAmount && parseAmount(body.sendAmount),
      receiveAmount: body.receiveAmount && parseAmount(body.receiveAmount),
-      grantId: ctx.grant?.grant
+      clientId: ctx.grant?.clientId


How will this have to change with #688?

I think we'd be able to keep our current logic of defining ctx.clientId for everything except read-all/list-all requests

rafiki/packages/backend/src/open_payments/auth/middleware.ts

Lines 80 to 84 in 3a3f9e8

// Unless the relevant grant action is ReadAll/ListAll add the

// clientId to ctx for Read/List filtering

if (access.actions.includes(action)) {

ctx.clientId = grant.clientId

}

mkurapov · 2022-11-30T17:41:38Z

packages/backend/src/open_payments/payment/outgoing/model.ts

+export class OutgoingPaymentGrant extends DbErrors(Model) {
+  public static get modelPaths(): string[] {
+    return [__dirname]
+  }
+  public static readonly tableName = 'outgoingPaymentGrants'
+  public id!: string
+}


Should this be in its own file? I was trying to find the model when I pulled down the branch originally, but wasn't able to right away

I wanted to go all in on confining this to outgoing payments.
Are you thinking a separate model file in this directory, or its directory with its own service?

Makes sense - I was thinking of having one model per file in general, but if its confined as such and won't grow beyond its current scope, then it's good here

mkurapov · 2022-11-30T17:44:18Z

packages/backend/src/open_payments/payment/outgoing/service.ts

-  //lock grant
-  await deps.grantReferenceService.lock(grant.grant, deps.knex)
+  // Lock grant
+  // TODO: update to use objection once it supports forNoKeyUpdate


Should there be a separate issue for this? Or too far out/uncertain just yet?

We have a PR that I could include in the comment

add forNoKeyUpdate and forKeyShare Vincit/objection.js#2319

I think it's ok for now. Also, I'm guessing reviews haven't been fast on this because of: Vincit/objection.js#2335. Would be good to keep an eye on this thread

wilsonianb · 2022-11-30T20:39:14Z

@wilsonianb It feels like the "RTP" is more of a general concept in this case right? i.e. RTP != RS?

In general, having more information about the grant would be a good thing IMO, could do further checks other than the clientId, for example...

I'm not sure if our RS is more like the RTP or FSP.

Either way, I think we should associate created resources with corresponding grants for auditing purposes. I think just storing the grant id on the resource is currently sufficient with the RS bound to the AS. (The single account provider can look up grant details in the AS db tables. Although maybe we'd need to expand admin api to do so.)
However, do we need that for incoming payments and quotes? If not, then this PR still provides association of outgoing payments with corresponding grants.

mkurapov · 2022-12-01T19:15:07Z

Yeah, because of how the RS & AS are tied together, all the info can be found in the AS anyway if an audit is needed. I like that this simplifies things a bit in general + we don't need extra DB calls for incoming payments & quotes. I could see this changes down the line but LGTM for now

wilsonianb added 2 commits November 29, 2022 16:48

chore(backend): add outgoing payment grants table

81e81d3

chore(backend): remove grant reference

f73b728

github-actions bot added pkg: backend Changes in the backend package. type: source Changes business logic type: tests Testing related labels Nov 30, 2022

This was referenced Nov 30, 2022

refactor(backend): add getOrCreate method for grantReferenceService #787

Closed

feat(backend): request grant to query incoming payment receiver #779

Merged

wilsonianb marked this pull request as ready for review November 30, 2022 00:57

wilsonianb requested review from sabineschaller, JoblersTune, dclipp and mkurapov November 30, 2022 00:57

sabineschaller approved these changes Nov 30, 2022

View reviewed changes

mkurapov reviewed Nov 30, 2022

View reviewed changes

mkurapov approved these changes Dec 1, 2022

View reviewed changes

wilsonianb merged commit cbbc416 into main Dec 1, 2022

wilsonianb deleted the bw-client-id branch December 1, 2022 19:54

mkurapov mentioned this pull request Dec 6, 2022

Add grantReferenceService.getOrCreate #703

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(backend): replace GrantReference with OutgoingPaymentGrant #800

chore(backend): replace GrantReference with OutgoingPaymentGrant #800

wilsonianb commented Nov 30, 2022 •

edited

Loading

sabineschaller left a comment

wilsonianb commented Nov 30, 2022

mkurapov commented Nov 30, 2022

mkurapov left a comment

mkurapov Nov 30, 2022

wilsonianb Nov 30, 2022

mkurapov Nov 30, 2022

wilsonianb Nov 30, 2022

mkurapov Dec 1, 2022 •

edited

Loading

mkurapov Nov 30, 2022

wilsonianb Nov 30, 2022

mkurapov Dec 1, 2022

wilsonianb commented Nov 30, 2022

mkurapov commented Dec 1, 2022

	// Unless the relevant grant action is ReadAll/ListAll add the
	// clientId to ctx for Read/List filtering
	if (access.actions.includes(action)) {
	ctx.clientId = grant.clientId
	}

chore(backend): replace GrantReference with OutgoingPaymentGrant #800

chore(backend): replace GrantReference with OutgoingPaymentGrant #800

Conversation

wilsonianb commented Nov 30, 2022 • edited Loading

Changes proposed in this pull request

Context

Checklist

sabineschaller left a comment

Choose a reason for hiding this comment

wilsonianb commented Nov 30, 2022

mkurapov commented Nov 30, 2022

mkurapov left a comment

Choose a reason for hiding this comment

mkurapov Nov 30, 2022

Choose a reason for hiding this comment

wilsonianb Nov 30, 2022

Choose a reason for hiding this comment

mkurapov Nov 30, 2022

Choose a reason for hiding this comment

wilsonianb Nov 30, 2022

Choose a reason for hiding this comment

mkurapov Dec 1, 2022 • edited Loading

Choose a reason for hiding this comment

mkurapov Nov 30, 2022

Choose a reason for hiding this comment

wilsonianb Nov 30, 2022

Choose a reason for hiding this comment

mkurapov Dec 1, 2022

Choose a reason for hiding this comment

wilsonianb commented Nov 30, 2022

mkurapov commented Dec 1, 2022

wilsonianb commented Nov 30, 2022 •

edited

Loading

mkurapov Dec 1, 2022 •

edited

Loading