-
Notifications
You must be signed in to change notification settings - Fork 90
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
chore(token-introspection): return client payment pointer, not key #1007
Conversation
@@ -171,7 +171,7 @@ export abstract class PaymentPointerSubresource extends BaseModel { | |||
public abstract readonly assetId: string | |||
public abstract asset: Asset | |||
|
|||
public readonly clientId?: string | |||
public readonly client?: string |
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.
My understanding is that we wouldn't always want to have this defined here because of subresource lookups in the local service (the service making the request itself)?
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.
A payment pointer subresource won't have a client
if it was created via the admin api instead of Open Payments
// clientId to ctx for Read/List filtering | ||
ctx.clientId = tokenInfo.client_id | ||
// filter by client for Read/List | ||
ctx.filterClient = 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.
ctx.filterClient = true | |
ctx.filterByClient = true |
@@ -42,7 +42,7 @@ async function getOutgoingPayment( | |||
try { | |||
outgoingPayment = await deps.outgoingPaymentService.get({ | |||
id: ctx.params.id, | |||
clientId: ctx.clientId, | |||
client: ctx.filterClient ? ctx.client : undefined, |
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.
When would we not want client
defined in routes > get methods?
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.
rafiki/packages/backend/src/open_payments/auth/middleware.ts
Lines 93 to 96 in 16a4f82
if (isActiveTokenInfo(tokenInfo) && tokenAction === requestAction) { | |
// Unless the relevant token action is ReadAll/ListAll add the | |
// clientId to ctx for Read/List filtering | |
ctx.clientId = tokenInfo.client_id |
^ previous naming with same behavior
We pass client
as undefined
to get
and list
methods when the grant allows ReadAll
/ListAll
, meaning we don't need to filter the query by client
.
// clientId to ctx for Read/List filtering | ||
ctx.clientId = tokenInfo.client_id | ||
// filter by client for Read/List | ||
ctx.filterClient = 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.
What if this logic lived at the route level, where we check there if the AccessAction === ReadAll || ListAll
there? Can store accessAction
or the whole tokenInfo
on the ctx
itself?
Just a thought
Changes proposed in this pull request
Context
Checklist
fixes #number