Yes, I tried that and that worked!!! So you were right. Also stepped throught the code and verified:
1) the authentication info getting cached is the hashed version 2) all the caching is saving is getting the info from disk, it is still hashing the passed in auth info all over again to compare to the info it gets from the cache So yes reducing the number of iterations immensely speeds this up, I vaguely remember now that I used 500000 a couple of months ago after reading some blog post that recommended upping the iterations for more security. Shows you the perils of following advice without completely understanding. What would be ideal would be if the caching would work like how you suggested, that is it would cache the plaintext after comparing and use that for the future as long as the cache entry existed. But right now it does the opposite, it caches the hashed info and hashes the plaintext username/password passed in and then does the comparison. Any quick ideas on how to tweak this to do what you suggested? Prefereably not involving heavy duty subclassing etc. :-) Thanks for all your help. ---- Saad -- View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html Sent from the Shiro User mailing list archive at Nabble.com.
