Saad, you're right. Shiro caches AuthenticationInfo having the credentials hashed. Then it is required hashing (over configured iterations) the token sent via request in order to match with the hashed AuthenticationInfo.
I can't say to you right now if this approach is right or wrong. But it seems that the hashing phase is required in a stateless application, after all, it would not be secure. -- D. Reinert On Fri, Nov 8, 2013 at 10:16 AM, saadmufti <[email protected]> wrote: > Hmm, I stepped into the code after disabling sessions and enabling > MemoryConstrainedCacheManager (also tried EhCacheManager), and it looked to > me like the obfuscated authentication info was getting cached, so Shiro was > still having to execute its hashing scheme with 500,000 iterations on the > password in every incoming request. But you seem to be saying that with > caching turned on, it should only need to do the hashing once (before the > info was cached). That is not what I was seeing. In my case even after > turning caching on all I was saving was the lookup of the stored > authentication info, I wasn't saving anything on the computation of the > obfuscated form of the incoming password. > > ---- > Saad > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579355.html > Sent from the Shiro User mailing list archive at Nabble.com. >
