-
Notifications
You must be signed in to change notification settings - Fork 34
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
[ANCHOR-380] Add client_id to getRate()
in Sep31Service
#1068
[ANCHOR-380] Add client_id to getRate()
in Sep31Service
#1068
Conversation
Reference Server Preview is available here: |
Something went wrong with PR preview build please check |
private String getClientIdFromToken(Sep10Jwt token) throws AnchorException { | ||
if (token == null || token.getAccount() == null) return null; | ||
// Get clientId if the client exists | ||
try { | ||
GetCustomerResponse customer = | ||
customerIntegration.getCustomer( | ||
GetCustomerRequest.builder().account(token.getAccount()).build()); | ||
return customer.getId(); | ||
} catch (NotFoundException nfex) { | ||
// skip only if customer not found. | ||
debugF("Unable to get customer {} from customer integration server.", token.getAccount()); | ||
} | ||
return null; | ||
} |
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 there is a misunderstanding of what clientId
is. Its not the ID of the customer requesting the quote.
From the documentation:
Client IDs will be the Stellar public key the public key used to authenticate via SEP-10. Anchors must ensure that > the public key specified in the request matches a public key known to belong to the sending anchor
This is only true for SEP-31 though. In SEP-24 & SEP-6, the client ID is either the Stellar public key of the wallet OR the wallet's domain.
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.
@Ifropc wants to replace usage of Stellar public keys with domains, even for custodial applications. For 1.x, we probably need to continue using Stellar public keys, but for 2.x we could use home domains if we require the clients.domain
field for each client.
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.
To clarify, not domains, but client name that's defined in the config (client.name
)
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.
From the spec
An identifier for the client application making the request
So I believe using client.name
is appropriate here, as initially the idea of introducing client.name
was to use it as application identification
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.
Oh, yeah, I was wondering about this and forgot to check the documentation.
I think the name client_id
is very confusing though. Should we change to client_account
? or client_stellar_account
?
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 am not familiar with the context of the client.name
. Can we add a Jira ticket for discussion?
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 have changed the client_id
to account
.
Reference Server Preview is available here: |
827b9de
to
e26aaa1
Compare
Reference Server Preview is available here: |
platform/src/main/java/org/stellar/anchor/platform/component/sep/SepBeans.java
Outdated
Show resolved
Hide resolved
.expireAfter(request.getExpireAfter()) | ||
.clientId(account) | ||
.build(); | ||
GetRateResponse.Rate rate = this.rateIntegration.getRate(getRateRequest).getRate(); | ||
.expireAfter(request.getExpireAfter()); | ||
|
||
// Sets the clientId if the customer exists | ||
String clientId = getClientIdFromToken(token); | ||
if (clientId != null) { | ||
getRateRequestBuilder.clientId(clientId); | ||
} | ||
GetRateRequest getRateRequest = getRateRequestBuilder.build(); |
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.
Firm quotes will always be authenticated, so we don't need to call getClientIdFromToken()
. If the token is null, we should throw an error, rather than handle it gracefully.
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.
The check of the authentication with the token is always done at the controller. We don't need to worry about them in the service layer. It makes simpler not to worry about authentication in the service layer.
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.
Great, so if the controller makes sure that the token is present, we don't need to check it clientId
is null and can just do
getRateRequestBuilder.clientId(token.getAccount())
private String getClientIdFromToken(Sep10Jwt token) { | ||
if (token == null) return null; | ||
return token.getAccount(); | ||
} |
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.
This works until we add support for using SEP-38 prices & quotes for SEP-24 & SEP-6 transactions. If we want to replace the usage of public keys and domains with client names, we can't merge this because it would be a breaking change to change clientId
from a public key to names defined in the config. cc @Ifropc
Reference Server Preview is available here: |
Reference Server Preview is available here: |
Reference Server Preview is available here: |
core/src/test/kotlin/org/stellar/anchor/sep31/Sep31ServiceTest.kt
Outdated
Show resolved
Hide resolved
getRate()
when possiblegetRate()
in Sep31Service
1ec1bed
to
af52a59
Compare
af52a59
to
879d262
Compare
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.
LGTM
343c9c1
to
b56df33
Compare
ClientConfig client = clientsConfig.getClientConfigBySigningKey(account); | ||
if (sep10Config.isClientAttributionRequired() && client == null) { | ||
throw new BadRequestException("Client not found"); | ||
} | ||
if (client != null && | ||
!sep10Config.getAllowedClientDomains().contains(client.getDomain())) { | ||
client = null; | ||
} | ||
return client == null ? null : client.getName(); | ||
} | ||
|
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.
ClientConfig client = clientsConfig.getClientConfigBySigningKey(account); | |
if (sep10Config.isClientAttributionRequired() && client == null) { | |
throw new BadRequestException("Client not found"); | |
} | |
if (client != null && | |
!sep10Config.getAllowedClientDomains().contains(client.getDomain())) { | |
client = null; | |
} | |
return client == null ? null : client.getName(); | |
} | |
if (sep10Config.isClientAttributionRequired()) { | |
if (client == null) { | |
throw new BadRequestException("Client not found"); | |
} | |
} else { | |
// client attribution not required | |
if (client == null) { | |
return null; | |
} | |
} | |
return client.getName(); |
Is this more clear?
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 this is still missing the logic that, even if we find the client, we should still return null if it's not in getAllowedClientDomains()
* | ||
* @return the list of allowed client domains. | ||
*/ | ||
List<String> getClientAttributionAllowList(); | ||
List<String> getAllowedClientDomains(); |
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.
Isn't it a breaking change?
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.
This should works just fine. Only the function name changed, the name of the config field staysclientAllowList
,
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.
How did you achieve 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.
Can you elaborate more on the question? We didn't touch the field clientAllowList
in Sep10Config..
The getClientAttributionAllowList
returns a list of allowed client domains (which is the intersection of sep10config.clientAllowList
and clientsConfig.clients
), since we are introducing a new function to return the name of same group of clients, it's better to make the naming
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.
Sorry didn't see SEP10 config is an interface
5542c6c
to
f1b2578
Compare
Please don't force-push if avoidable @JiahuiWho |
### Description Clean up dead code. All uses has been removed in #1068 ### Context Better engineering
Description
Fix the bug where
client_id
was not passed togetRate()
when the customer of the wallet exists.Context
Bug fix
Testing
./gradlew test