Hi Tim, First of all, welcome to the Shiro community, and great work on the GitHub application. It is nicely done and well explained! I'll try to address your questions below.
On Sun, Nov 20, 2011 at 11:49 AM, timniblett <[email protected]> wrote: > I'm planning to use AppEngine for a project, and would like to use > Shiro for authentication. I've spent a few days playing with it and > have a demo at http://gaeshiro.appspot.com with code checked in at > https://github.com/cilogi/gaeshiro. I'm also using Guice to organize > the code. > > The demo explains what I'm trying to do. > > Not being familiar with Shiro I have a couple of questions/issues. > > - I can't see the point of using the Guice module (I /am/ using > Guice). The ini configuration seems fine and I don't see what extra > one gets from Guice here. I'm very likely missing something! Shiro's INI is pretty powerful, but sometimes complex object graph configuration (SecurityManager or any of its internal components) might be better suited for direct configuration with a DI framework like Guice (or Spring, or Tapestry, etc). It is really up to you to use whatever is convenient. One benefit of using DI-only configuration (No Shiro INI) is that if you configure an object in your DI container, and you need to reference it in a Shiro-related object, it might be easier to do so if using only the DI framework (i.e. no need to re-define or re-instantiate just for the INI config needs). Another benefit is that you only have one config mechanism to worry about (no need to jump between config files if that matters to you). There might be other configuration 'niceness' provided by your DI framework that Shiro doesn't support. While I can't speak to Guice, Spring for example has something called a 'PropertyPlaceholderConfigurer' that allows me to read in a property file and have all referenced properties in my DI object graph reflect the .properties file (e.g. a properties 'override' mechanism). Shiro has no such functionality at the moment. So, this is just one example. If Shiro's INI works fine for you, then keep using it. If you find that config is becoming a bit harder trying to organize between Shiro and Guice, you might want to use just one. > - What's the best way to handle caching with App Engine & Shiro? I've set up > something with GAE's memcache service but there are 4 methods in the > interface (clear, size, keys and value) which can't be implemented with > memcache. Are these needed -- is memcache not a good idea? Cache.clear() and Cache.keys() and Cache.size() are not used by other components in Shiro's codebase at all - they are there as a convenience for you. (perhaps they should be deprecated). Cache.values() is used by the CachingSessionDAO which is used only in a native session management scenario - when Shiro manages sessions and not the container. If you're using GAE to manage sessions for you, there is no nee to worry about this method either. All other methods in the Cache interface are used well enough, especially if you use authentication and/or authorization caching. Memcache would be a good option for these types of operations. > - Apart from the non-use of https, which is deliberate, are there any > security gotchas I'm missing? I'd definitely increase the number of hash iterations you use when hashing passwords. 200,000 at a minimum - maybe more depending on how fast the hosted hardware is. It won't slow down login or password reset that much and is a good mechanism to make passwords even safer. I haven't fully looked at the codebase, but that's one recommendation. HTH. > - Are there any tips for speeding up the initialization of Shiro on GAE? Shiro's default setup (SecurityManager and its default internal components) are _extremely_ lightweight. They shouldn't take but milliseconds to fully initialize. If for some reason it has to be as fast as humanly possible, you can avoid using the INI config and configure the Shiro components directly in code. The INI config 1) needs to be parsed and 2) uses reflection for setting object graph children. Naturally this is slower than direct code, but in practice it is still so fast that most people don't care about the minor increase in time. Your project needs should dictate how fast is fast enough. I hope that helps - I hope you enjoy using Shiro! Best, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
