restapi: Remove sensitive response fields for non-admin users

[Artemi10]

Non-admin users can access detailed information such as MTU, CPU information, library information and other internal configuration data through network, host and storage domain API.This commit adds logic to remove these fields from responses for non-admin users to prevent unintentional data exposure. Fields that are required by the VM Portal are retained to ensure existing functionality is not broken.

Changes introduced with this PR

1. Remove all fields from Hosts API except "id", "name", "address", "cluster.id" for non-admin user

• Before fix
  

• After fix
  

2. Remove all fields from Networks API except "id", "name", "data_center.id" for non-admin user

• Before fix
  

• After fix
  

3. Remove all fields from Storage Domains API except "id", "name", "type", "permissions", "storage.type", "available", "used", "status", "data_center.id" for non-admin user

• Before fix
  

• After fix
  

Are you the owner of the code you are sending in, or do you have permission of the owner?

Yes

[dupondje]

Search for isFiltered() in the backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/*** files.
This should be implemented the same way then for additional fields you want to hide.

[Artemi10]

Search for isFiltered() in the backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/*** files. This should be implemented the same way then for additional fields you want to hide.

@dupondje
Thanks for pointing that out!

I looked into the isFiltered() implementation in the backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/*** files, but I noticed a potential issue: it respects the filter query parameter even for non-admin users. This means a non-admin could explicitly set filter=false in the request header and potentially bypass data filtering, which might expose sensitive information.

To avoid this, implemented a separate method isAdmin(). This way, I only check user permissions and do not take any request headers into account, ensuring stricter access control.

protected boolean isAdmin() {
DbUser user = getCurrent().getUser();
return user.isAdmin();
}