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

[ANCNHOR-626] Update ClientsConfig with SigningKeys and Domains #1355

Merged
merged 7 commits into from
May 13, 2024

Conversation

JiahuiWho
Copy link
Contributor

@JiahuiWho JiahuiWho commented May 8, 2024

Description

  • Deprecate signing_key and domain, replace with signing_keys and domains
  • Remove signing_key field for noncustodial client (usage only found in validation)
  • Replace the use of signing_key and domain with signing_keys and domains in related function and test cases

Testing

  • ./gradlew test

Documentation

Will update in https://developers.stellar.org/network/anchor-platform/admin-guide/sep10

@JiahuiWho JiahuiWho changed the title [ANCNHOR-626] Update ClientsConfig [ANCNHOR-626] Update ClientsConfig with SigningKeys and Domains May 9, 2024
@JiahuiWho JiahuiWho marked this pull request as ready for review May 9, 2024 19:59
@lijamie98
Copy link
Collaborator

Can we add tests that has multiple signing_keys and multiple domains?

@JiahuiWho
Copy link
Contributor Author

Can we add tests that has multiple signing_keys and multiple domains?

Yes I have changed PropertyClientsConfigTest.kt to use signingKeys and domains for testing, in this way we can test with multiple values

I will add tests for getClientConfigBySigningKey and getClientConfigByDomain to validate it

@@ -42,7 +43,7 @@ public String getClientName(String clientDomain, String account)
throw new SepNotAuthorizedException("Client not found");
}

if (clientDomain != null && !isDomainAllowed(client.getDomain())) {
if (clientDomain != null && !isClientDomainsAllowed(client)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This check looks like a legacy.
We define allowed clients in the clientAllowList (which allows all clients by default), and based on allowed clients we get allowed domains (using configured clients).
So, this will always be matching the check below, because allowed domains are gathered from allowed client. So it will always be true if client name is allowed and false otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, but only if we know the client is in clientAllowList for sure. I saw the only call site is the Sep10Service, where the account and domain were extracted from request and passed down here, but does it guarantee the client find is allowed?

If this is the case we should also either move or rename the function indicating this is for Sep10 use only, ClientFinder is just too general and the validation should be there for other cases.

Copy link
Contributor

Choose a reason for hiding this comment

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

If it's not in clientAllowList, wouldn't isClientNameAllowed also be false?

Copy link
Contributor Author

@JiahuiWho JiahuiWho May 13, 2024

Choose a reason for hiding this comment

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

I see. This check is redundant, we only need to check the name.

Copy link
Contributor

@Ifropc Ifropc left a comment

Choose a reason for hiding this comment

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

LGTM!
If you could, do you mind adding tests to check backward compatibility? (i.e. checking that when domain is defined, domains is automatically set to set of one domain and same for custodial key)
Just to ensure backward compatibility is covered by the test

@@ -12,8 +12,10 @@ public interface ClientsConfig {
class ClientConfig {
String name;
ClientType type;
String signingKey;
String domain;
@Deprecated String signingKey; // ANCHOR-696
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice!!

Copy link
Collaborator

@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
Copy link
Contributor Author

LGTM! If you could, do you mind adding tests to check backward compatibility? (i.e. checking that when domain is defined, domains is automatically set to set of one domain and same for custodial key) Just to ensure backward compatibility is covered by the test

Yeah test for postConstruct() is added to PropertyClientsConfigTest

@JiahuiWho JiahuiWho merged commit f46d75a into stellar:develop May 13, 2024
8 checks passed
@JiahuiWho JiahuiWho deleted the anchor-626-update-clients-config branch May 13, 2024 23:35
@@ -596,9 +591,9 @@ String getClientName(String account) throws BadRequestException {
if (sep10Config.isClientAttributionRequired() && client == null) {
throw new BadRequestException("Client not found");
}
if (client != null && !sep10Config.getAllowedClientDomains().contains(client.getDomain())) {
System.out.println(Arrays.toString(sep10Config.getAllowedClientNames().toArray()));
Copy link
Contributor

Choose a reason for hiding this comment

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

sout should be removed @JiahuiWho

JiahuiWho added a commit that referenced this pull request Jun 4, 2024
### Description

[[ANCNHOR-626] Update ClientsConfig with SigningKeys and
Domains](#1355)
introduced change to ClientsConfig,
merge develop to bring feature/v3 up to date

### Context

Merge `develop` into `feature/v3`

### Testing

- `./gradlew test`

---------

Co-authored-by: Philip Liu <[email protected]>
Co-authored-by: Jamie Li <[email protected]>
Co-authored-by: Kanwalpreet Dhindsa <[email protected]>
Co-authored-by: Gleb <[email protected]>
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.

4 participants