Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/536#discussion_r33479990
--- Diff:
api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java ---
@@ -203,9 +201,22 @@ public void execute() {
hostResponse.setObjectName("host");
hostResponses.add(hostResponse);
}
-
response.setResponses(hostResponses, result.second());
}
+ // Remove sensitive details from host response
+ List<HostResponse> hostResponsesList = response.getResponses();
+ for (HostResponse hostResponse: hostResponsesList) {
+ Map<String, String> hostDetails = hostResponse.getDetails();
+ if (hostDetails == null) continue;
+ if (hostDetails.containsKey("username")) {
+ hostDetails.remove("username");
+ }
+ if (hostDetails.containsKey("password")) {
+ hostDetails.remove("password");
+ }
+ hostResponse.setDetails(hostDetails);
--- End diff --
@jburwell The HostResponse created by service layer is being consumed at
several places such as AddHostCmd, UpdateHostCmd, ReconnectHostCmd etc. while
the details are set in HostJoinDaoImpl (much lower layer than the service
layer), this is why I thought the best fix would be to fix the response in
ListHostsCmd before it is wired back to the client.
The response class gets instantiated in the current request thread and is
not referenced by any other threads or components, that's why it's safe to
simply manipulate the map in the response class without adding the overhead of
copying it. It's safe in this context, though I agree with the immutable
pattern you're proposing here - I can add code to copy the details map instead
of manipulating it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
