On Tue, Feb 23, 2010 at 4:25 PM, Arjun Nair <[email protected]> wrote: > 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.
Well, I don't know if here is more related with browser cache than with Acegi security cache. I believe that when a rest service is called from a browser (through Ajax capabilities) the browser may cache or not user credentials. In case of XX-7641 I think that the problem was more related with the fact that the browser continuously asked for user login when a REST service call attempt was done (ignoring cache). Mircea > > 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/
