I have a question about the way setACL functions. It seems that the
PreRequestProcessor handles all kinds of requests the same, checks the
validity of the corresponding ACL, and enqueues them to Sync and Final
processors. Maybe I am missing something here, but this behaviour seems
weird. What if a setACL request comes, setting the ACL of a path (e.g. /
) to an IP (e.g. 188.8.131.52) , instead of its old value (e.g. World).
This request will pass the ACL check, and will be enqueued to be
processed by the next processors. Assume that the next request is a
getData("/") from an IP other than 184.108.40.206. If this request is
processed by the PreRequestProcessor before the setACL request is
processed by the FinalRequestProcessor, then it will pass the ACL check
(which it should not, since it came after the setACL request). It seems
that there is a race condition here that should not exist.
Let me know if this is actually the case or I am missing something. I am
using version 3.0.1 of the code.
- setACL semantics Manos Kapritsos