where did acl 80005 (disabled_extensions) go? #303
-
It seems that between commit 41a9894 (#PR254) and HEAD commit b6b9839 (#PR302) the support of disabled_extensions attribute in waflz profile has changed. It seems HEAD version does not support the attribute. Is it correct observation? Edit: It's PR256 "no more acl inside profile" Edit2: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
We moved the access control lists into their own "entity" type which takes it's own json that can be loaded in a similar fashion to the waf profiles. Here's an example using Here's a basic acl config (json) with just one extension blocked: {
"disallowed_extensions": [
".xxx"
]
} Running ~/gproj/waflz/build>./util/waflz_server/waflz_server --port 12345 --acl ./my_cool_acl.json
... Then ~>curl -s localhost:12345/index.xxx | jq '.'
{
"rule_msg": "File extension is not allowed by policy",
"sub_event": [
{
"rule_id": 80005,
"rule_msg": "File extension is not allowed by policy",
"rule_target": [
{
"name": "RklMRV9FWFQ=",
"param": "disallowed_extensions"
}
],
"rule_op_name": "",
"rule_op_param": "",
"rule_tag": [
"HTTP POLICY"
],
"matched_var": {
"name": "RklMRV9FWFQ=",
"value": "Lnh4eA=="
}
}
],
"acl_config_id": "",
"acl_config_name": "",
"config_last_modified": ""
} There's a lot you can do with the access lists including:
And some parts from the originating client request that can be targeted (including):
Let us know if you have more questions! |
Beta Was this translation helpful? Give feedback.
We moved the access control lists into their own "entity" type which takes it's own json that can be loaded in a similar fashion to the waf profiles.
Here's an example using
waflz_server
(utility server built withwaflz
)Here's a basic acl config (json) with just one extension blocked:
Running
waflz_server
(listening on port 12345) from the build dir:Then
curl
ing from another terminal