Skip to content
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

Merged

Conversation

lijamie98
Copy link
Collaborator

Description

Fix the bug where client_id was not passed to getRate() when the customer of the wallet exists.

Context

Bug fix

Testing

./gradlew test

@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

@stellar-jenkins
Copy link

Something went wrong with PR preview build please check

Comment on lines 261 to 274
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;
}
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

@Ifropc Ifropc Aug 29, 2023

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)

Copy link
Contributor

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

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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.

@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

@lijamie98 lijamie98 self-assigned this Aug 29, 2023
@lijamie98 lijamie98 force-pushed the feature/anchor-380-missing-client-id branch from 827b9de to e26aaa1 Compare August 29, 2023 06:25
@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

Comment on lines -361 to +378
.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();
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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())

Comment on lines +528 to +531
private String getClientIdFromToken(Sep10Jwt token) {
if (token == null) return null;
return token.getAccount();
}
Copy link
Contributor

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

@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

@stellar-jenkins
Copy link

Reference Server Preview is available here:
https://anchor-ref-pr1068.previews.kube001.services.stellar-ops.com/
SEP Server Preview is available here:
https://anchor-sep-pr1068.previews.kube001.services.stellar-ops.com/

@lijamie98 lijamie98 changed the title [ANCHOR-380] Add client_id to getRate() when possible [ANCHOR-380] Add client_id to getRate() in Sep31Service Sep 13, 2023
@JiahuiWho JiahuiWho force-pushed the feature/anchor-380-missing-client-id branch from 1ec1bed to af52a59 Compare September 14, 2023 20:15
@lijamie98 lijamie98 force-pushed the feature/anchor-380-missing-client-id branch from af52a59 to 879d262 Compare September 14, 2023 20:43
Copy link
Collaborator Author

@lijamie98 lijamie98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@JiahuiWho JiahuiWho force-pushed the feature/anchor-380-missing-client-id branch from 343c9c1 to b56df33 Compare September 18, 2023 19:05
@lijamie98 lijamie98 assigned JiahuiWho and unassigned lijamie98 Sep 18, 2023
Comment on lines 579 to 588
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();
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Contributor

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();
Copy link
Contributor

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?

Copy link
Contributor

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,

Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

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

@JiahuiWho JiahuiWho force-pushed the feature/anchor-380-missing-client-id branch from 5542c6c to f1b2578 Compare September 18, 2023 20:39
@JakeUrban
Copy link
Contributor

Please don't force-push if avoidable @JiahuiWho

@JiahuiWho JiahuiWho merged commit b53c3f3 into stellar:develop Sep 18, 2023
5 checks passed
JiahuiWho added a commit that referenced this pull request Feb 27, 2024
### Description

Clean up dead code.
All uses has been removed in
#1068

### Context

Better engineering
@JiahuiWho JiahuiWho deleted the feature/anchor-380-missing-client-id branch July 31, 2024 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants