You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked at the code, but I couldn't find how it isolated HTTP requests from one another.
It seems that if two requests from two users arrive at the same time, both will setup signal handlers, and receive all modifications (even those made by the other user), using the memory-global "registry" to. If so, this is a serious bug, since audit-log becomes unreliable, stuffing the wrong user into the wrong model instance.
Am I missing something ine the signal dispatching system ? Or does django-audit-log
only work with single-threaded servers?
The text was updated successfully, but these errors were encountered:
I can confirm this is an issue for multithreaded servers. We didn't use this package but we had the basically the same logic for user assignment and yes it was a complete nightmare. Millions of records in the database had the wrong user assigned. What triggered the investigation on this issue was when some deleted a user and many critical records in the database got deleted because of the cascade delete we had in place.
I looked at the code, but I couldn't find how it isolated HTTP requests from one another.
It seems that if two requests from two users arrive at the same time, both will setup signal handlers, and receive all modifications (even those made by the other user), using the memory-global "registry" to. If so, this is a serious bug, since audit-log becomes unreliable, stuffing the wrong user into the wrong model instance.
Am I missing something ine the signal dispatching system ? Or does django-audit-log
only work with single-threaded servers?
The text was updated successfully, but these errors were encountered: