Mircea Carasel wrote: > On Mon, Feb 22, 2010 at 11:33 AM, George Niculae > <[email protected]> wrote: >> Hi All, >> >> while working on XX-7673 - I found the following security issue: >> 1. log in user 200 / PIN 1234 >> 2. log out user 200 >> 3. log in superadmin, change PIN for user 200 to 1111 >> 4. log in again with user 200 / PIN 1234 - this works even the PIN was >> changed in the previous step. >> >> Another scenario is to delete user 200 at step 3 - step 4 will result in a >> UI crash with hibernate exception. >> >> This problem is due to configured acegi user cache that keeps user details >> in memory for 2 minutes (when step 4 is executed the user details are not >> fetched from the database but are retrieved from user cache). >> >> I can see 2 ways to solve this: >> - use a null user cache - that's it, no cache to be kept >> - register a dao listener that removes users from cache when a user is >> deleted / saved >> >> Personally I vote for the 2nd one since the cache might be useful >> >> Please share your thoughts, >> > I am thinking that a 2 minutes cache is a good outfit from acegi and > should be kept. Imagine that we have thousands of users that are > stressing the system in an *enterprise* sipXecs solution. I believe > that this cache would reduce overhead and improve sipXecs performance > in such environment. > I vote also for the 2nd solution >
When I was looking at XX-7641 [1], I recall that the REST authentication tokens (for the now unused Date REST API) were being cached across JVM restarts. I did not pursue it further, as we are now no longer using the API. In fact, XX-7641 as a whole, we did not really fix the root problem, we just got rid of the component that was causing it. I wonder how much of a part the cache played in it. In terms of performance gains, I definitely agree the cache is a good thing, but IMO, we are going to get a lot more mileage by optimizing some of the HQL queries than caching the auth tokens. So, in short I think we need to spend more time investigating the cache, and I am not sure if it's worth doing so in this release at least. Maybe we could disable it, and look at it properly for the next release. What do you think? Arjun [1] http://track.sipfoundry.org/browse/XX-7641 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
