Re: [mod-security-users] Collection not finding a set variable
Brought to you by:
victorhora,
zimmerletw
From: Christian B. <ch...@jw...> - 2010-07-08 17:44:36
|
Hi Chris! Interesting issue you have here. Am 08.07.2010 um 14:49 schrieb Chris Datfung: > Every so often I see intances of ModSecurity set a session variable and then not be able to retrieve the variable later on. In other words, I have a rule that creates a SESSION.username variable, which gets set as follows: > > [08/Jul/2010:09:30:24 +1000] > [xxx.xxx.xxx/sid#8fb6de7][rid#cfa8c10][/index.asp][9] Set variable "SESSION.username" to "123456". > > but sometimes (and only sometimes) when I try to use the SESSION.username variable the variable does not resolve to a value. When this happens I don't see "Resolved macro %SESSION.username" in the logs, but I do see the "Set variable "SESSION.username to ..." which tells me that the variable is set, but sometimes seems to disappear. Has anyone experienced this before? In a recent discussion, we came across the same thing. After implementing some session-collection based rules and inspecting them with the collection viewer (from the jwall-tools), it seemed that ModSecurity lost track of some variables. Josh just mentioned the issue didn't show up anymore after restructuring the order of his rules, putting the session-collection based rules in front, IIRC. The question which rises up to me is: 1) Have you been able to reproduce this? Did this happen in all requests to /index.asp or only single/specific ones? 2) Did that happen with a single request being processed? Or was there a second request being processed in parallel? A good hint might be, if you could check whether the setvar-stuff has been called very close to another request causing "setvar" to be executed (regarding the timestamps in your debug.log). Perhaps Brian can shortly elaborate on the way the storage works. I did have a short look at the code, but I am not 100% sure if concurrent requests causing the same collections to be written/loaded might not cause a race-condition here. Regards, Chris |