You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/policy-management.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -118,7 +118,7 @@ A PUT completely replaces the policy within the scope of the client.
118
118
The PUT works as a combination of DELETE and POST. It requires a body with the same content type as the [POST request](#creating-policies). This body will be interpreted as the requested policy with some rules.
119
119
120
120
The PUT process:
121
-
1. Find information about the policy. If it does not exist, return with a **status code 400** to indicate that you cannot rewrite a nonexistent policy.
121
+
1. Find information about the policy. If it does not exist, return with a **status code 404** to indicate that you cannot rewrite a nonexistent policy.
122
122
2. Parse and validate the body, with the same procedure used in the POST endpoint. First, we perform the basic sanitization checks. Upon success, extra checks are performed to see if the new definition stays within the scope of the client:
123
123
- Check that the newly defined policy does not define other policies
124
124
- Check that the new policy does not contain any rules that do not belong to the client
@@ -143,7 +143,7 @@ The PATCH process:
143
143
- Performing DELETE queries on rules out of your scope will simply not work, since they are not part of the isolated store.
144
144
- We can easily see exactly when the query goes out of scope by testing the resulting store, separating it in the 5 groups and performing the following checks:
145
145
1. If the resulting store has rules out of the clients' scope (indicated by groups **(2)** and **(5)**), we can abort the update and respond with **status code 400**.
146
-
2. We can analyze the size of the resulting store. Substracting the amount of quads within reach should result in 0, since no other rules may be added. This test will fail when the client inserts any unrelated quads to its own policy. Upon failure, the server responds with **status code 400**.
146
+
2. We can analyze the size of the resulting store. Substracting the amount of quads within reach should result in 0, since no other rules may be added. This test will fail when the client inserts/deletes any unrelated quads to its own policy. Upon failure, the server responds with **status code 400**.
147
147
4. The old definition will be replaced with the updated version. Since no real update function for our storage exists, we delete the old policy and add the resulting store from the query, together with the quads out of scope as collected in step 1.
148
148
149
149
Note that any quads in the original policy that could not be collected by the procedure defined in [GET One Policy](#get-one-policy), will not be part of the newly defined policy.
@@ -155,8 +155,8 @@ The DELETE process:
155
155
1. Find the rules defined in the policy.
156
156
2. Filter the rules that are assigned by the client, and delete them.
157
157
3. Find out if there are rules not assigned by the client.
158
-
*if there are other rules, we cannot delete the policy information as well. We delete the rule and its definition triple in the policy.
159
-
*if there are no other rules, we can delete the entire policy.
158
+
*If there are other rules, we cannot delete the policy information as well. We delete the rule and its definition triple in the policy.
159
+
*If there are no other rules, we can delete the entire policy.
160
160
161
161
This method used to have one rather significant issue, as discussed [later](#delete-fix).
0 commit comments