Les, Thanks very much for your comprehensive reply. I'm very grateful.
I take your point about Guice being quicker on set-up due to lack of parsing. Its very hard to tell how much time the Shiro ini takes, but my reading of the Yourkit entrails indicates that the start-up time is largely down to the data store (at least on the development server). The example you've got in the documentation uses an ini file /and/ Guice, so you won't get this advantage... This may just be me & my app, but for something lightweight its useful to be able to have the admin users (and perhaps a guest) hard-wired into the ini file (although its should be the salted hash of course). If I didn't use the ini file for this I'd need a more complicated user data store. It's very difficult for me, coming in fresh to Shiro, to judge whether to use the Guice extension. The example in the documentation /can/ be done with an ini file (and of course uses one), and the ini file is more transparent. I guess it would take a real use-case where Guice integration has concrete advantages to persuade me. A large part of what sells Shiro is how simply your "standard" examples fit into my needs. It took an amazingly small amount of time to create the App Engine adapter (which seems to work...). In any case it might be useful to point out how one can use Shiro and Guice _without_ the extension in about 4 lines of code. I can see that the cache values() method is only used to get a list of (non web) sessions. If we go by the principle that you should never trust a cache then I guess that's OK. There was a certain amount of FUD on my part in omitting/cheating on part of the base interface -- I'd have been more comfortable with the base Cache interface being minimal and consistent with distributed caches. Failing that, marking some methods as optional (as with Java collections and (say) Iterator.remove()) would help remove the FUD. I take the point about multiple iterations for the password hash. I have it set to 1 for the demo but more would be safer. I've gone for a minimum of 6 characters in the password (only enforced in the JS). I don't have a feel for what the best trade off between a secure password and unhappy users is... ---- Finally, another question. I'm pretty sure I need to provide a basic id (name/password) for users, but this should be a backup and users should be able to use their ids on Google, Facebook, etc. if they wish. I suspect that providing a social login will be much more acceptable to many users (it certainly is to me). I want to integrate social login with the demo in as convenient a way as possible. Do you have any recommendations for a library to integrate? A cursory search throws up * Gigya * Janrain * Google Identity Toolkit (poor choice of acronym) * socialauth The first 2 charge, Google might at some point I guess, but is free now. The advantage of these 3 is a single registration. socialauth is Open Source but one does have to register your site with each service you want to use which is a pain. I'd like to set up something which will be easy for others to use -- I don't have much of a feel for requirements though. Again, thanks for your reply. I appreciate it. Shiro has been a joy to work with so far. Tim -- View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-on-App-Engine-tp7014377p7020285.html Sent from the Shiro User mailing list archive at Nabble.com.
