add missing response body to blocked requests

[micbar]

Description

Adds the missing response body to blocked requests.

Examples

{
    "error":{
        "code":"deniedByPolicy",
        "message":"Operation denied due to security policies",
        "innererror":{
            "date":"2023-05-10T19:52:19Z",
            "filename":"policies.yaml",
            "method":"POST",
            "path":"/remote.php/dav/spaces/storage-users-1$some-admin-user-id-0000-000000000000",
            "request-id":"5e55a8ad-cd5f-40c9-a002-db9e30f24585"
        }
    }
}

{
    "error":{
        "code":"deniedByPolicy",
        "message":"Operation denied due to security policies",
        "innererror":{
            "date":"2023-05-10T20:05:00Z",
            "filename":"Neue Datei.md",
            "method":"PUT",
            "path":"/remote.php/dav/spaces/storage-users-1$some-admin-user-id-0000-000000000000/Neue Datei.md",
            "request-id":"9302a92e-c7eb-4c41-9a98-62eb37cf5db4"
        }
    }
}

Related Issue

• Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[AlexAndBear]

I don't think we want to have request denied at top level. This makes it hard to have a generic error handler.

Otherwise I like it

[micbar]

@michaelstingl This is a proposal to have a unified response body for all requests which are blocked by the policy engine to enable all clients to distinguish them. In a second step and in the scope of a cross platform initiative we should introduce server translated error messages.

[micbar]

I don't think we want to have request denied at top level. This makes it hard to have a generic error handler.

Otherwise I like it

use error ?

[AlexAndBear]

I wouldn't nest it personally, because the http status code indicates the error already, but that's just personal preference. Error as top level is fine for me as well.

[micbar]

Error as top level is fine for me as well.

It is the same like libregraph. So keeping error at the top level makes it consistent.

[AlexAndBear]

💪

That's fine, maybe it's pretty neat to have it. Because in the future we might have error and errors and trough that we could have implementations for different interfaces.

Anyways: I would start the message with capital letter. In the end this is what the user reads (en).

(The operation ...)

[micbar]

Anyways: I would start the message with capital letter. In the end this is what the user reads (en).

Ok. Maybe a misunderstanding on my side. I thought we agree on a fixed string for now which will be translated in web.

[AlexAndBear]

Sure sure sure. But let's start this thing off properly and give it a handy message from the beginning, so that an English user gets a neat message.

We will translate it in web but when we change that in the future, you don't need to replace the English strings later ;)

[micbar]

Ok, tried to give it a meaningful and short message.

Operation denied due to security policies

@tbsbdr @kulmann

[ownclouders]

💥 Acceptance test localApiTests-apiGraph-ocis failed. Further test are cancelled...

[ownclouders]

💥 Acceptance test localApiTests-apiCors-ocis failed. Further test are cancelled...

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication