Ability to set msg in subsequent chained rules

[void-in]

Currenlty, the msg can be set only by the starting SecRule statement in a chained rule which is often configured to work in phase 1 and no other information is available in here other than HTTP headers. For example, there is no way to log POST_VARS to the log message if the first rule operates in phase 1.

It is suggested to either make the msg be set by any SecRule in a chained rule or have the ability to edit the contents of msg.

[csanders-git]

message can take a variable which can be modified by later rules (which is currently how we deal with this). What is your suggestion in terms of priority? The last message takes precedence? The first takes precedence?

[void-in]

@csanders-git If we have the ability to set the message in all SecRules of a chian, then the last one should take precedence (that sounds more logical since msg will be treated as an attribute which can be modified by subsequent calls). The reason I wanted this was because I was working on a use case to block logins into an application from a particular country. However, I wanted to log the application usernames as well. I attempted to do this like:

SecGeoLookupDb <path to GeoIP.dat>
SecRule REQUEST_BODY "username=(\w{1,})" "phase:2,capture,chain,deny,id:12345,msg:'Login attempt from country X with username with %{TX.1}'"
SecRule REMOTE_ADDR "@geoLookup" "chain,t:none"
SecRule GEO:COUNTRY_CODE "!@streq XX"

However, this might not be the most efficient method as the rules are processing phase 2 first (for usernames) and then phase 1 for REMOTE_ADDR. Is there a better alternative? Thanks for having such a wonderful project and for your response.

[csanders-git]

So let me address these one at a time because they are good questions. Currently messages in a chained rule are not displayed until the entire rule has returned true. So I can see where it would be useful to have this in the last rule essentially we'd have to scan the entire rule for multiple msg actions. and pick out the last one - This essentially makes the rule put the message in the location where you have access to the vars you need. This is slightly difficult to explain but better than combining the scope of all the variables. Perhaps we should include this in libmodsecurity

[csanders-git]

On your second note.
Here we have a bit of explaining to do:
To quote @dune73 from last week "[phase] 1 used to be the phase run after the requests headers where received. But then people constantly complained the rules in containers as directory / location would simply be ignored (container springing into action only when the request body was received). So Ivan Ristić gave up and pushed phase 1 on the same apache hook as phase 2.
So to summarize even though it seems inefficient these are both done at essentially the same time.

[void-in]

@csanders-git Thanks a lot for the explanation. Yes it make sense even if there is a performance penalty.