Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4EB419A3.3060209@christopherschultz.net>
Date: Fri, 04 Nov 2011 12:58:11 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
CC: Pete Gould <pete.gould@gmail.com>
Subject: Re: CsrfPreventionFilter - LRU cache
References: 
 <CADz1Fz_huKVpb_yiiA6Zj-2HF4TmDd7UmNdFJRU2jdKNF3JELQ@mail.gmail.com>
In-Reply-To: 
 <CADz1Fz_huKVpb_yiiA6Zj-2HF4TmDd7UmNdFJRU2jdKNF3JELQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pete,

On 11/4/11 9:14 AM, Pete Gould wrote:
> I have recently been using the
> org.apache.catalina.filters.CsrfPreventionFilter, and I notice that
> the documentation for setNonceCacheSize states:
> 
> "Sets the number of previously issued nonces that will be cached on
> a LRU basis to support parallel requests..."
> 
> However, looking at the implementation of the cache, it appears to
> be a FIFO implementation rather than a LRU cache. I'm happy to
> raise a bug and supply a patch for whichever is the desired
> implementation, but need to determine what the original intention
> is first - based on the Javadoc it would suggest that the intention
> is for the cache to be LRU, could anyone here confirm that?

That's my expectation: LRU means to remove the element that was least
recently used.

> In order to act as an LRU cache, the LinkedHashMap(int
> initialCapacity, float loadFactor, boolean accessOrder) constructor
> would need to be used with accessOrder set to true.

+1

> Also the add and contains methods would need to be altered as
> follows, as "LinkedHashMap.containsKey" does not act as a 
> structural modification.
> 
> public void add(T key) { synchronized(cache) { cache.put(key,
> key); } }


I'm not sure add() needs to change.

> public boolean contains(T key) { synchronized(cache) { return
> cache.get(key) != null; } }

+1

> Either cache implementation will work for the majority of cases,
> however I came across this issue when issuing Ajax requests which
> repeatedly use the same nonce string and after 5 requests the value
> I'm using is ejected from the (FIFO) cache, changing the cache to
> LRU fixes this (although could potentially result in the same token
> being used for N requests).

Good catch.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk60GaMACgkQ9CaO5/Lv0PBQXwCgltBfdKYoJLnCLEHWgnm5ryV4
s3kAn0K9L4tz2XnzqoHhFSO07EsmINfk
=ba9N
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org