CertService: Fix account id requirement by using caller account id as fallback - #13818
CertService: Fix account id requirement by using caller account id as fallback#13818resmo wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Aligns CertService SSL certificate listing behavior with other CloudStack APIs by falling back to the caller’s account when no explicit accountId (and no other filter like project/LB/cert) is provided, removing an unnecessary hard requirement that caused client friction (e.g., automation modules).
Changes:
- Update
listSslCertsto use the caller account ID as the default whenaccountIdis not provided. - Add a unit test ensuring the no-filter case queries certificates for the caller’s account.
- Minor cleanup: parameterized logging and correct string comparison for key algorithm checks.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| server/src/main/java/org/apache/cloudstack/network/ssl/CertServiceImpl.java | Implements caller-account fallback for listing certs; minor logging/string-compare adjustments; updates PEM reader close handling. |
| server/src/test/java/org/apache/cloudstack/network/ssl/CertServiceTest.java | Adds a regression test validating caller-account fallback behavior for listSslCerts. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
server/src/main/java/org/apache/cloudstack/network/ssl/CertServiceImpl.java:375
- The comment and logic here are misleading: this block is not about "encryption for DSA"; it conditionally performs an RSA signature round-trip to validate that the keypair matches, and it skips validation for any non-RSA algorithm (not just DSA). Consider updating the comment and using a null-safe string comparison for clarity.
// No encryption for DSA
if (!pubKey.getAlgorithm().equals("RSA")) {
return;
}
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #13818 +/- ##
=========================================
Coverage 19.64% 19.65%
- Complexity 19790 19791 +1
=========================================
Files 6368 6368
Lines 574889 574897 +8
Branches 70353 70354 +1
=========================================
+ Hits 112962 112982 +20
+ Misses 449656 449637 -19
- Partials 12271 12278 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (2)
server/src/main/java/org/apache/cloudstack/network/ssl/CertServiceImpl.java:206
- The owner-selection condition can silently ignore a provided
accountNamewhendomainIdis missing because it usesStringUtils.isNotEmpty(...)as a gate. This bypasses_accountMgr.finalizeOwner(...)validation (which would throw whenaccountName != null && domainId == null), and the current&&/||expression is also hard to read due to operator precedence. Consider keying onaccountName != null(not non-empty) and grouping theprojectId/accountNamecases explicitly so invalid parameter combinations are rejected instead of being ignored.
Account owner = null;
if (StringUtils.isNotEmpty(listSslCertCmd.getAccountName()) && listSslCertCmd.getDomainId() != null || listSslCertCmd.getProjectId() != null) {
owner = _accountMgr.finalizeOwner(caller, listSslCertCmd.getAccountName(), listSslCertCmd.getDomainId(), listSslCertCmd.getProjectId());
} else {
owner = caller;
api/src/main/java/org/apache/cloudstack/api/command/user/loadbalancer/ListSslCertsCmd.java:28
import org.apache.cloudstack.api.response.*;introduces a wildcard import, which is inconsistent with the surrounding API command classes in this package that use explicit response imports (e.g. CreateLoadBalancerRuleCmd.java:30-34, DeleteSslCertCmd.java:27-28). Using explicit imports avoids accidental unused dependencies and keeps diffs more readable.
import org.apache.cloudstack.api.response.*;
streamline ssl cert list api, deprecate accountid
1d05a20 to
8a3871f
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (1)
server/src/main/java/org/apache/cloudstack/network/ssl/CertServiceImpl.java:203
- The owner resolution condition mixes && and || without parentheses and only calls finalizeOwner when (accountName && domainId) or projectId is set. This means invalid combinations like specifying accountName without domainId are silently ignored (finalizeOwner would normally throw), and it also allows ambiguous requests when accountId is supplied together with account/domainId or projectId. Consider computing a single
hasOwnerParamsflag, callingfinalizeOwnerwhenever any owner-related parameter is provided (so validation/permission checks run), and rejecting combinations that include both deprecatedaccountIdand the new owner parameters.
Account owner = null;
if (StringUtils.isNotEmpty(listSslCertCmd.getAccountName()) && listSslCertCmd.getDomainId() != null || listSslCertCmd.getProjectId() != null) {
owner = _accountMgr.finalizeOwner(caller, listSslCertCmd.getAccountName(), listSslCertCmd.getDomainId(), listSslCertCmd.getProjectId());
Description
While implementing an ansible module for ssl cert (ngine-io/ansible-collection-cloudstack#178). I faced this api and experienced this issue. (As a side note: The ssl cert api is IMHO not consistent with other cloudstack apis: e.g. there are no domainId with accountName param but an accountId.)
SSL cert service requires to set the account id (if no project id or lb id), however, this is inconsistent to other cloudstack APIs where (AFAICS) the caller account name is used instead as a fallack.
UPDATE:
I added another commit on top to streamline the api by adding
accountanddomainidto the list api. Let's discuss which way to go.This change aligns with this behaviour.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?