I believe that the common way for REST APIs to address this is to use short-lived auth tokens. This basically gives you the same thing as the sessions without the "stateful" part of sessions. On Nov 7, 2013 6:23 PM, "Josh Berry" <[email protected]> wrote:
> One real quick suggestion, if you can, go ahead and enable sessions. I > believe that gets you basically what you want. When the user is > successfully authenticated, from that point on you will actually be relying > on the session cookie instead of the authentication cookie. If the > "session" is ever not found, you then create a new one and authenticate it. > > I realize this breaks the "stateless rest" backend, and I have far from > thought it through. Just an idea that occurred to me as being rather easy > to get running. > > > On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <[email protected]> wrote: > >> To be fair, more iterations is a good idea. I'll try and take a look this >> evening and see if i can figure something out. >> On Nov 7, 2013 4:04 PM, "saadmufti" <[email protected]> wrote: >> >>> 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. >>> >> >
