fix: Status codes for Space Disable/Delete

Allow a "permission denied error" from reva to bubble up to the client.
Reva was fixed to return "permission denied" only when the space to be
delete can actually be listed by the user. Other wise it will return
"not found". See reva commit 1bf72cb76394671f373e87f15f23f978cf41ab08.

So when a user with the 'can manage' role tries to purge an already
disabled space it will now get "Forbidden" status instead of a "Not
found".

Also fixes the expected status codes in the tests.

(cherry picked from commit 99d80f30a9)
This commit is contained in:
Ralf Haferkamp
2026-06-18 16:43:03 +02:00
parent b25367a845
commit 92a2980875
3 changed files with 23 additions and 20 deletions

View File

@@ -1119,7 +1119,7 @@ func (g Graph) DeleteDrive(w http.ResponseWriter, r *http.Request) {
return
case cs3rpc.Code_CODE_PERMISSION_DENIED:
logger.Debug().Interface("id", rid).Msg("could not delete drive: permission denied")
errorcode.ItemNotFound.Render(w, r, http.StatusNotFound, "drive not found")
errorcode.AccessDenied.Render(w, r, http.StatusForbidden, "permission denied")
return
case cs3rpc.Code_CODE_NOT_FOUND:
logger.Debug().Interface("id", rid).Msg("could not delete drive: drive not found")

View File

@@ -63,28 +63,28 @@ Feature: Disabling and deleting space
Scenario Outline: user cannot delete their own space without first disabling it
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
When user "Alice" deletes a space "Project Moon"
Then the HTTP status code should be "400"
Then the HTTP status code should be "<code>"
And the user "Alice" should have a space called "Project Moon"
Examples:
| user-role |
| Admin |
| Space Admin |
| User |
| User Light |
| user-role | code |
| Admin | 400 |
| Space Admin | 400 |
| User | 403 |
| User Light | 403 |
Scenario Outline: user can delete their own disabled space via the Graph API
Scenario Outline: user cannot delete their own disabled space via the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
And user "Alice" has disabled a space "Project Moon"
When user "Alice" deletes a space "Project Moon"
Then the HTTP status code should be "204"
And the user "Alice" should not have a space called "Project Moon"
Then the HTTP status code should be "<code>"
And the user "Alice" <shouldOrNot> have a space called "Project Moon"
Examples:
| user-role |
| Admin |
| Space Admin |
| User |
| User Light |
| user-role | code | shouldOrNot |
| Admin | 204 | should not |
| Space Admin | 204 | should not |
| User | 403 | should |
| User Light | 403 | should |
Scenario Outline: an admin and space manager can disable other space via the Graph API
@@ -134,7 +134,7 @@ Feature: Disabling and deleting space
Scenario Outline: viewer and space editor cannot disable space
When user "<user>" tries to disable a space "Project Moon" owned by user "Alice"
Then the HTTP status code should be "404"
Then the HTTP status code should be "403"
And the user "<user>" should have a space called "Project Moon"
Examples:
| user |

View File

@@ -152,11 +152,14 @@ Feature: Space management
Scenario Outline: space admin user tries to disable the personal space
When user "<user>" disables a space "Alice Hansen" owned by user "Alice"
Then the HTTP status code should be "404"
Then the HTTP status code should be "<code>"
Examples:
| user |
| Brian |
| Carol |
| user | code |
# Brian is Space Admin and can currently list all Personal Spaces, so he
# gets a 403 instead of a 404 here. This might change in the future see:
# https://github.com/opencloud-eu/opencloud/issues/2979
| Brian | 403 |
| Carol | 404 |
Scenario: space admin user deletes the project space