I have only been reading along, sorry @sandro
I realised that Matteo, I realised that
Don’t worry, I have my own Cloudflare employee who is somewhat ignoring me
So this is an interesting situation. If we hide the repeats, how do you know if it’s still working? I get it’s annoying, however it’s still a Firewall event, and there is still a challenge being actioned, and a rule being actioned.
Correct me if I am wrong, but as far as I understand it there is no challenge being actioned as it has already passed the initial one and does posses the required cookie at this point.
The Firewall Rule is still triggering a check and validation of the cookie. What is really missing here, and this is something we’re working on figuring out, is “passed or failed”. That’s really the issue you’re facing right? Knowing whether they’re hitting it and failing?
To be honest, no
It would be interesting to know whether the first challeged was passed or not. Subsequent requests (for successful challenges) are not really important. If I have a page with 300 embedded elements, I will have 301 challenges in that even list - that is somewhat counterproductive (unless it is going to be a real log, which can be properly filtered, grepped, etc.).
Got it, makes sense. I’ll pass that feedback over to the team and see what options we’ve got. Challenge we have is that all our customers are different, so whilst it’s annoying for you, other customers believe it’s important.
Yes, this is very important. I see many requests that go directly to a .jpg file on my website. Sometimes they come in two subsequent requests (I’m assuming they are requesting http, then https), but since these files, unlike an HTML page, do not ask for a subsequent file to be requested, I never know whether these hits where let in or not. (Unless I check timestamp against my origin server access log)
I’d love to have a proper access log but I wouldnt dare ask for that .
My point with this thread simply is that the event log is sort of flooded the moment there is challenge in place and these entries are not for challenged requests (that would be desired) but for validated requests which simply originate from the first (challenged) request.
But should this get me access to a proper access log - with all requests - I shall be happy .
Hmm… didn’t @cbrandt just have a thread where the answer was that when they passed, it would show as whitelisted? Yet here it’s still showing jsChallenge.
These are firewall rules, not user agent rules.
Still inconsistent, though, no?
Different rule engines, different mess
I just really hope the rule consolidation will manage to fix these issues.
maybe subsequent event listings be tagged as a threaded addition to initial challenge and can be accessed as a expanded link which unhides them ? Similar to how Gmail auto hides already read or older replies in an email subject thread ? Or have them link/expanded in Details area.
That would most definitely be an idea, however I still think the entries following the initial challenge are wrong in the first place as these requests are not challenged to begin with.
The event log is supposed to show requests which triggered one of the defined rules. This is the case for the initial request but not anymore for the subsequent ones.
@alexcf, any possible update on this? It really clutters the log
Sorry for bumping this once again but right now filtering for challenged requests really is pretty useless
We can’t really supposed these, but what clearly would be helpful here is some method “filtering” out events. I’ll speak to the team and figure out what we can do when we build in the new Firewall Event Log for Self-Serve plans.