I want to match this pattern in my spamassassin's filtering rules:
Password archivio: 666
Per conto di:
There is a space after di: and the number can be of undefined digits.
in my custom.cf I have created this rule
body CUSTOM_SPAM_RULE /Password\sarchivio:\s\d+\n\n\nPer\sconto\sdi:\s/
score CUSTOM_SPAM_RULE 99.9
describe CUSTOM_SPAM_RULE Regola di spam custom
I have checked the regex with an online tool and is working, you can check it here https://regex101.com/r/O3BfDK/1 but I have no hits in my mail gateway, the server side configuration is working cause if I change the rule to a simple regex like \test\ and send an email with a body containing test, I can clearly watch the hits. So, what I'm missing?
ok found it in official spamassassin's documentation
Rawbody rules Rawbody rules allow you to search the body of the email without certain kinds of preprocessing that SA normally does
before trying body rules. In particular HTML tags won't be stripped
and line breaks will still be present. This allows you to create rules
searching for HTML tags or HTML comments that are signs of spam or
nonspam, or particular patterns of line-break.
so the correct rule becomes
rawbody CUSTOM_SPAM_RULE /Password\sarchivio:\s\d+\n\n\nPer\sconto\sdi:\s/
score CUSTOM_SPAM_RULE 99.9
describe CUSTOM_SPAM_RULE Regola di spam custom
Related
I added a new rule for deny all the external requests to 'actuator' .(spring endpoints) as following:
The rule works as expected until I am using partial decode URL like:
<host>/%61ctuator
Do you know any way or a better to define a rule like that that block encoded URLs as well?
Cloud Armor recently released additional operator functionality that will allow for URL decoding of attributes within a given CEL rule match.
For example:
request.path.lower().urlDecode().contains("/actuator")
I've setup an experiment on a specific URL in which I send no traffic
(same domain name that I use for other landing pages but with different parameter in the URL)
I've started the experiment few days ago without sending any traffic
And now I see that the experiment got triggered around 5000 times.
I double checked on my analytics reports and I see no access to the main page that is supposed to trigger the test. To explain with example:
This is what I have running:
http://domain1/landingpages?id=1
http://domain1/landingpages?id=2
this is the test that I created:
http://domain1/landingpages?id=3
with a 50% redirect on:
http://domain1/landingpages?id=4
The Experiment should only be triggered on id=3 page, but it did got triggered with id=1 and id=2 pages. Any idea how I can make the trigger only happen when "id=3" is in the url ?
Currently my configuration is as follow:
"WHEN Url Matches "http://domain1/landingpages?id=3" "
The URL targeting documentation explains your situation. (Emphasize by me.)
Use matches when there are query string parameters in URLs that you
don’t want to include in the matching. Matches can be more flexible
than equals because it adheres to the following rules:
Ignores query string parameters and fragments.
Case insensitive.
Normalized to remove a www. prefix.
Normalized to a remove a trailing slash.
HTTP and HTTPS are optional (HTTP will match HTTPS).
Verifying this in Optimize:
So you should either simply select Equals operator and use http://domain1/landingpages?id=3 as a value.
If other parameters might occur, then you could build a regex for this, to containt id=3 among various parameters. E.g.:
http:\/\/domain1\/landingpages\?(.*&)?id=3(&|$)
Optionally, you can use Query parameter targating, and build a rule for the base URL, and for the id parameter separately.
How can I verify if an incoming field is a valid e-mail? Is there a way to use string-functions or anything in Firestore security rules?
Example:
Let's say I have a Create-Request with a field called "email". In my Firestore security rules, I would like to check if the email is a valid email address:
contains '#'
ends with either .xx or .xxx (a casual country-domain-ending)
has a '.' before the last three or two letters of the email
the '.' does not follow directly after the '#' - at least two letters have to be in-between
So that e.g. example#emailprovider.com gets accepted, but not example#.com.
I know that this check is quite extensive and further would like to know if it makes sense to introduce such a validation to security rules?
You can use rules.String.matches.
See
https://firebase.google.com/docs/reference/rules/rules.String#matches
https://github.com/google/re2/wiki/Syntax
How to validate an email address using a regular expression?
Performs a regular expression match on the whole string.
A regular expression using Google RE2 syntax.
If you want to set only email address then It's necessary to validate the field as email address.
I found an example of a regex (and adjusted a bit):
^[a-zA-Z0-9._%+-]+#[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,5}$
The source of this is at the bottom of the following page:
https://firebase.google.com/docs/reference/security/database/regex
You should also take into account the note as well:
Note: THIS WILL REJECT SOME VALID EMAILS. Validating email address
in regular expressions is difficult in general. See this site for
more depth on the subject.
-I'm using a number of WordPress rewrite rules to allow for the injection of country-codes immediately at the beginning of the URL path, which are used to determine a timezone offset. An example:
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]&post_type=days','top');
This takes a request like www.daysoftheyear.com/days/2011/ (which would usually return all valid content for this request) and allows for, e.g., www.daysoftheyear.com/us/days/2011/ to return the same content but with support for a timezone offset based on the country-code.
This works fine in almost all places, with the exception of a single query type - one for 'days' custom post type pages, e.g., http://www.daysoftheyear.com/days/waffle-day/.
The rules I have in place are:
add_rewrite_rule('^([A-Za-z]{2})/?$', 'index.php?geo=$matches[1]','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]$matches[3]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/([0-9]+)/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]$matches[3]$matches[4]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([A-Za-z\-].*)/?$', 'index.php?geo=$matches[1]&page=$matches[2]','top');
add_rewrite_rule('^([A-Za-z]{2})/([A-Za-z\-].*)/?$', 'index.php?geo=$matches[1]&pagename=$matches[2]','top');
The fifth rule shoud match http://www.daysoftheyear.com/gb/days/waffle-day/ in much the same way as above, but redirects - I suspect that it's confliucting with the inbuilt rules which attempt to redirect to a correct URL if it's malformed (e.g., if I type a close structural match to a correct URL, it'll redirect me to the correct resource).
I can confirm that the 'raw' URL for this request works - e.g., http://www.daysoftheyear.com/index.php?geo=en&name=soup-month&post_type=days returns a valid and expected result.
I'm not convinced this is a regex rule, rather than a specific challenge with the way WP manages custom post types?
EDIT
Updated to allow for hyphens - no change in behaviour, though regexpal reports that the regex works against the example URL.
Updated after disabling WP canonical redirects functionality - now 404'ing rather than 301'ing to the page.
Updated to use 'page' rather than 'pagename', based on the information here: http://codex.wordpress.org/Class_Reference/WP_Query#Post_.26_Page_Parameters - no change in behaviour.
Updated the code, added a linebreak and clarified that I'm actually referencing line 5, rather than line 4.
This request http://www.daysoftheyear.com/days/waffle-day/ won't match your fourth rule since you didn't allow - inside the group cature : ([A-Za-z].*). Replace this group with ([A-Za-z\-].*) and it should match.
HTH
Resolved; it appears that the above ruleset now works correctly - thanks all!
I need to allow the user to submit queries as follows;
/search/"my search string"
but it's failing because of request validation, as outlined in the following 2 questions:
How to include quote characters as a route parameter? Getting "Illegal characters in path" message
How to modify request validation?
I'm currently trying to figure out how to disable request validation for the quote character, but i'd like to know the risks before I actually put the site live with this disabled? I will not disable the request validation unless I can only disable it for the quote character, so I do intend to disallow every other character that's currently not allowed.
According to the URI generic syntax specification (RFC 2396), the double-quote character is explicitly excluded and must be escaped (i.e. %22). See section 2.4.3. The reason given in the spec:
The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields.
You can see easily why this is the case -- imagine trying to create a link in HTML to your URL:
<a href="http://somesite/search/"my search string""/>
That would fail HTML parsing (and also breaks SO's syntax highlighting). You also would have trouble doing basic things with the URL like emailing it to someone (the email client wouldn't parse the URL correctly), posting it on a message board, sending it in an instant message, etc.
For what it's worth, spaces are also explicitly excluded (same section of the RFC explains why).