Is there an easy way to do that outside of just enabling short lived sessions and not putting anything in them? (That is, only use them to store a validated user?)
On Thu, Nov 7, 2013 at 9:30 PM, Jared Bunting <[email protected]>wrote: > 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. >>>> >>> >>
