Site.save on dynamic site causes APIError

[crypticgeek]

When attempting to modify a dynamic site (for instance, changing an alert), calling Site.save results in an APIError:
<ajaxResponse success="0"> <Errors> <Error>Insufficient privileges to remove credentials</Error> </Errors> </ajaxResponse>

However I did not modify the credentials of the loaded site and static sites do not give the same error. Am I unaware of something that's different about handling dynamic sites? The documentation only mentions that connection and asset filter changes must be saved through the DiscoveryConnection#update_site call.

[crypticgeek]

The script's nexpose user has the following privileges:
Appear on Ticket and Report Lists
Manage Tags
View Site Asset Data
Specify Site Metadata
Manage Scan Alerts
View Group Asset Data
Create Reports
Create Tickets

I specifically do not want this user to have too many privileges, so I've been very specific in the ones assigned. It is my assumption that the manage scan alerts privilege should be sufficient.

[mdaines-r7]

The underlying problem is that each change of the site also requires the site configuration to be saved. This includes credentials, including global credentials. I'd tried to work the save method in such a way that it grabs the credentials when Site#load is called, storing them so they can be included in the save operation. (Sorry, dynamic site saving isn't "supported" through the API, so I've had to engineer it through backdoors.)

For the site where you see the problem, are their global credentials, site credentials, or both? I'll try to test each of these scenarios, but if I know your specific case, I'll focus on that first.

[crypticgeek]

Ah, I see. That's unfortunate but I suspected it was an API limitation I wasn't aware of that the gem was working around.

One site is using both types and one site is using only shared credentials.

Thanks for your help.

[mdaines-r7]

I spent some time looking into this, and it isn't a simple fix. The dynamic site saving through the gem currently only works if the user has permission to change everything about the site. I was able to work around the credential problem, then hit up against a lack of permissions to save the dynamic criteria (which dynamic site saving attempts to do automatically on save). Even if I fixed this, it would break people who wanted to change credentials on a dynamic site.

In the near future, we are planning to collapse dynamic and static sites in the Nexpose UI. When that happens, it should also mean cleaning up how dynamic sites are saved. I'll have to check into what the timeline for that is, since it's another team working on it.

[crypticgeek]

Well, I can change the permissions but I have them configured that way to avoid totally borking my production Nexpose install. I'm not very experienced with the API / nexpose or automation on a large scale and since I don't have a test environment, I am (carefully) testing my scripts as I write them but unfortunately running against production none-the-less. Who cares if I mess up alerts or tags, but actually messing up the site's configured assets or scan credentials would be not good. I guess now's the time to figure out how to get myself a test environment for script testing. Thanks for looking into this in any case.