I am trying to convert the following rule to HAPROXY rule but it is not working for some reason. maybe somebody can help.
CF Rule
(http.request.method eq "GET" and http.request.uri.query eq "" and http.request.version eq "HTTP/1.1" and any(len(http.request.headers.values[*])[*] gt 60) )
Cloudflare Firewall Rules Page:
(https://developers.cloudflare.com/firewall/cf-firewall-language/fields#dynamic-fields
"Documentation")
Tried something simple without http version and query string, but still not working.
HAPROXY:
acl test1 hdr_cnt() gt 60
http-request deny if METH_GET test1
also tried with same method below and it didn’t work
req.fhdr_cnt
Related
I used the following haproxy configuration in frontend to modify the response header of requests depending on a query string:
frontend my-frontend
acl is-foo urlp(foo) 1
http-response replace-header Set-Cookie "(.*)" "\1; SameSite=None" if is-foo
Depending on my information from the docs the acl should match for all requests like
example.com?a=b&foo=1&bar=2
example.com?foo=1
example.com?a=b&foo=1
And it should not match for requests like
example.com?a=b&foo=0&bar=2
example.com?a=b
example.com?a=b&foo=bar
The actual result is that the acl matches never.
If i invert the if i.e.: if !is-foo the replace-header happens on every request.
So the problem must be the acl which matches never.
I use haproxy 2.0.15
I got it working by myself.
It seems to be the case that urlp(foo) is not present at runtime when it has been executed for http-response.
So we need to store its value in a temporary variable using set-var(custom.name), before. At runtime in if condition we can access it with var(custom.name) and match it against our condition. I used urlp_val() instead of urlp() here because the value will be casted to int immediately.
frontend my-frontend
http-request set-var(txn.foo) urlp_val(foo)
http-response replace-header Set-Cookie "(.*)" "\1; SameSite=None" if { var(txn.foo) eq 1 }
Thank you for traveling.
My question looks a lot like this one but the accepted answer does not correspond to my target usage :
I would like to set url once and for all in an initialize.feature file, and never set it again afterwards. In other words I don't want to clutter every single feature files with the same following statement :
* url baseUrl
My baseUrl value is set based on karate.env, e.g. https://localhost for local environment and http://prod.env.com for prod. It does not change.
path will change in our feature files because we test different endpoints.
I tried the following setup :
in karate-config.js :
config.baseUrl = 'https://localhost';
// ... code changing config.baseUrl based on karate.env == 'prod' or not
var result = karate.callSingle('classpath:utility/initialize.feature', config);
in initialize.feature :
#ignore
Feature:
Scenario: Initialize
* print baseUrl
* url baseUrl
We can see that baseUrl is correctly printed when executing initialize.feature file.
But in any executed feature afterwards, I get the following error :
some-test.feature:24 - url not set, please refer to the keyword documentation for 'url'
Is it possible to set url only in my initialize.feature file, and never afterwards ?
Thanks.
No, you can't. You will have to do * url baseUrl at least once in every feature file. There are multiple reasons for this - readability and maintainability for one, and if you look at the "hello world example" - note how you could omit the url in the second call because you are following the REST-ful patterns.
Since you can do * url baseUrl in the Background: and have all other Scenario-s inherit - this is normally ok in practice, and in real-life API testing we see that you do need to switch URL-s within a test (e.g. for auth). If you feel very strongly about this - you could consider a pull-request. FWIW this is the first time in 2.5 years that someone has ever requested this.
I'm running Apache Drill out-of-the box in embedded mode.
When I send a POST request to localhost:8047/query.json, it produces 400 with error:
Cannot construct instance of `org.apache.drill.exec.server.rest.QueryWrapper`, problem: null
at [Source: (org.glassfish.jersey.message.internal.EntityInputStream); line: 4, column: 1]
Request:
{
"QueryType": "SQL",
"Query": "SELECT count(*) as `cnt` FROM dfs.`/data/demo/Parquet/*.parquet`"
}
Content-Type: application/json
When running in distributed mode it happens as well.
Running query through web interface seems ok ...
According to google I'm the only one with this error.
Any ideas?
There was a dumb bug in the request.
The fields in the request must be in camelCase, not QueryType but queryType. There were capital 'Q's in previous request due to wrong serializer settings.
I did not notice this detail for a hour.
This works:
{
"queryType": "SQL",
"query": "SELECT count(*) as `cnt` FROM dfs.`/data/demo/Parquet/*.parquet`"
}
It would be nice if the API returned a normal error like "queryType is missing" instead of enigmatic Cannot construct instance of org.apache.drill.exec.server.rest.QueryWrapper.
Hope this will save somebody a hour of life.
We have recipe which use node attribute:
python_pip 'request_proxy' do
virtualenv '/opt/proxy/.env'
version node.default['request-proxy']['version']
Chef::Log.info('Auth request proxy #{version}')
action :install
end
Attribute is set on node level and everything is OK, but for test purposes i want to override it in my local (kitchen/vagrant) node. As first step i add attribute to my .kitchen.yml:
suites:
- name: default
run_list:
- recipe[proxy_install]
attributes: {request-proxy: {'version': '1.0.8'}}
Unfortunately node still use the "default" version. Everything works fine, without any error and completly ignores my attributes.
Later i tried add this to parameter file (chef-client -j params.json) on production node, result was the same.
What I missed? What am I doing wrong?
P.S. Chef::Log.info('Auth request proxy #{version}') is also completely ignored ??
Can you try using YAML? kitchen.yml is not a JSON file, so I'm not sure that your JSON embedded inside it would work.
attributes:
request-proxy:
version: '1.0.8'
Also, you probably should not be using node.default, unless you want to pick up the default value only (and never any overrides). If you want to use the attribute precedence (default, normal, override, force) in Chef, you should be doing:
node['request-proxy']['version']
Finally, you also have a single-quoted string with a variable. This will never work like you expect in Ruby (are you running rubocop? It would have caught this). Try it with double quotes, and remove it from the middle of your resource:
Chef::Log.info("Auth request proxy #{version}")
I am setting up a new Linux-Server and I am editing sshd_config. I will use protocol version 2 (which is default anyway):
Protocol 2
But in the default config-file I also find this two lines:
KeyRegenerationInterval 3600
ServerKeyBits 768
Manpage sshd_config(5) says about KeyRegenerationInterval:
In protocol version 1, the ephemeral server key is automatically
regenerated after this many seconds (if it has been used). The purpose
of regeneration is to prevent decrypting captured sessions by later
breaking into the machine and stealing the keys. The key is never
stored anywhere. If the value is 0, the key is never regenerated. The
default is 3600 (seconds).
So I know what this parameter does in SSH1. But I don't use SSH1. I use the default version SSH2, but the manpage gives no information about the effect of KeyRegenerationInterval in protocol version 2. Has KeyRegenerationInterval any effect in protocol version 2? And what about ServerKeyBits?
What will happen if I leave this settings in the config file when I set Protocol 2? What will happen when I delete those two lines?
I guess that those two parameters are ignored if protocol version is set to 2. But this is just guessed. From what I read until now I can't know for sure. Do you KNOW (not guess) what effect KeyRegenerationInterval and ServerKeyBits have in SSH2?
I'm sure that you already know this. I just didn't want to leave the question unanswered. These options (KeyRegenerationInterval & ServerKeyBits) affect the server key that is generated for SSH protocol 1. You should not have to worry about this if you demand that your connections adhere to protocol 2.
TL;DR: No, these options have no effect in SSH-2 (and SSH-1 support is removed since 2016).
When unsure, source code is the best documentation.
If we search for ServerKeyBits and KeyRegenerationInterval in the entire OpenSSH source code, we find only this in servconf.c:
{ "serverkeybits", sDeprecated, SSHCFG_GLOBAL },
. . .
{ "keyregenerationinterval", sDeprecated, SSHCFG_GLOBAL },
. . .
case sDeprecated:
case sIgnore:
case sUnsupported:
do_log2(opcode == sIgnore ?
SYSLOG_LEVEL_DEBUG2 : SYSLOG_LEVEL_INFO,
"%s line %d: %s option %s", filename, linenum,
opcode == sUnsupported ? "Unsupported" : "Deprecated", arg);
while (arg)
arg = strdelim(&cp);
break;
In other words, both options simply print a deprecation warning and have further no effect.
Then using the blame feature we find that the options were removed in the commit c38ea6348 of Aug 23, 2016 (OpenSSH 7.4p1):
Remove more SSH1 server code: * Drop sshd's -k option. *
Retire configuration keywords that only apply to protocol 1, as well as the
"protocol" keyword. * Remove some related vestiges of protocol 1 support.
Before that they were used only for SSH-1. E.g. KeyRegenerationInterval:
{ "keyregenerationinterval", sKeyRegenerationTime, SSHCFG_GLOBAL },
. . .
case sKeyRegenerationTime:
intptr = &options->key_regeneration_time;
goto parse_time;
Used in sshd.c/L1442:
if ((options.protocol & SSH_PROTO_1) &&
key_used == 0) {
/* Schedule server key regeneration alarm. */
signal(SIGALRM, key_regeneration_alarm);
alarm(options.key_regeneration_time);
key_used = 1;
}
Note: for SSH-2 there's a more powerful RekeyLimit.
For proto 2, there's this :
RekeyLimit
Specifies the maximum amount of data that may be transmitted
before the session key is renegotiated, optionally followed a
maximum amount of time that may pass before the session key is
renegotiated. The first argument is specified in bytes and
may have a suffix of 'K', 'M', or 'G' to indicate Kilobytes,
Megabytes, or Gigabytes, respectively.
The default is between '1G' and '4G', depending on the cipher.
The optional second value is specified in seconds and may use
any of the units documented in the TIME FORMATS section.
The default value for RekeyLimit is default none, which
means that rekeying is performed after the cipher's default
amount of data has been sent or received and no time based
rekeying is done.
Source :
https://www.freebsd.org/cgi/man.cgi?sshd_config(5)