dennisgsmith
commented
10 months ago @ScottMassa Thanks for reporting this issue. This falls in line with our discussion in the Sprint Planning meeting about a month ago and is due to some historical reasons in the MIDAS API.
Summary
For a quick fix, @KevinJJackson can hide this button on the UI from users. Are you able to send a screenshot of the exact button/page that should be hidden?
A fix has been deployed in https://github.com/USACE/instrumentation-ui/pull/193
Detail
MIDAS has only ever done this check on the client (UI) and the buttons are simply hidden from users based on their project role. It has never been enforced by the server -- any user with a MIDAS account on the network can make requests to the private group, which is not ideal.
There are 4 types of external request groups for the API (all restricted by USACE network):
public(does not need to be registered user)private(must be registered user, pass key auth or CAC, but not a member or admin of any project)cacOnly(must be registered user, pass CAC, but not a member or admin of any project)applicationAdmin(superuser, only select number of users, manually granted by developer)
To correctly implement project role authentication, we want to add project-level restrictions to specific endpoints that use the private and/or cacOnly groups. It actually looks like the functionality is partially implemented in the API codebase but was never completed. In order to complete this, it would require us to have well-defined permissions for each endpoint (for example, which endpoints should be project member vs project admin, etc.).
If you could supply me with a list of endpoints and their respective project roles via email, I can finish the implementation, based on the endpoints defined in the swagger doc: https://develop-midas-api.rsgis.dev/swagger/index.html. Alternatively, depending on your availability, we can set up a meeting to discuss this synchronously.
ScottMassa
Non Admin and Non User was able to enter data into a collection group
Was notified that a user from Louisville District was asked to enter data into a collection group on a project they were not a member (user or admin). Data was populated into the database.
Expected behavior
Would not have access to write to the database.
Actual behavior
User was able to submit a timeseries record that got populated into the database.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
I can request user name and project if necessary.