Agreed. What to do tactically for v0.9? I think that since EHCache
was the default cache for RC1-3 we should stick with it. Following
the same lines of reasoning SimpleAccountRealm should also stay the
same for v0.9. So, all that remains to be done is to put ehcache back
into the v0.9 line.
All of this will, of course, be fixed for the v1.0 release.
Thoughts?
Regards,
Alan
On Nov 7, 2008, at 8:15 AM, Jeremy Haile wrote:
Yeah, I think that if I dropped JSecurity into my project, I
wouldn't expect it to work out of the box with no configuration
whatsoever. I certainly wouldn't expect to see it firing up a realm
and loading in users and passwords loaded from the JAR.
If we DO want to support that sort of scenario at all (perhaps for
quickly getting projects up and running, etc.) - then I think we
could just allow users to set a flag like enable.test.realm=true.
I like making JSecurity easy to setup right out of the box in a
minimal way, but don't feel comfortable having it magically work
with no configuration - and having the user not even know where it's
loading usernames and passwords from. I think we could make it as
simple to setup as saying "realm=file, file=user.properties" or
whatever. Bam - two config properties and you're up and running -
and now there's no magic or confusion involved in where the data or
realm is coming from.
On Nov 7, 2008, at 11:08 AM, Alan D. Cabrera wrote:
Yeah, I dug up that conversation and re-read it. I agree,
SimpleAccountRealm needs to be reworked. I also agree that there
should be no default realm. Having default realms, in the security
world, strikes me as scary. Though I do see that it's compelling
to have something totally work out of the box, I think that in this
case the easy of use argument as crossed the line.
Regards,
Alan
On Nov 7, 2008, at 7:49 AM, Jeremy Haile wrote:
We initially made the decision to not fallback to
HashtableCacheManager because it is not suitable for a production
environment. So, if you put EhCache in your classpath then it
uses that, otherwise it disables caching.
However - I think SimpleAccountRealm, etc. depending on a cache
implementation is probably wrong. Those realms should definitely
fall back to using a hashtable or something else, probably
printing out appropriate warnings. (e.g. WARN - Falling back to
Hashtable implementation. This is NOT suitable for production
environments. Instead, enable a CacheManager implementation - see
JSecurity documentation for details)
In fact, I really don't like the fact that JSecurity has a default
realm at all - I think the user should have to specify something,
even if we make it extremely easy. (e.g. setting a single property
to enable the default realm)
Thoughs?
Jeremy
On Nov 7, 2008, at 5:04 AM, Peter Ledbrook wrote:
This class attempts to use EhCacheManager as the default cache
manager, if
Ehcache is in the classpath. If it's not, then there is no
cache manager.
This breaks SimpleAccountRealm and anything that inherits from
it, i.e.
PropertiesRealm, the default realm. So, if Ehcache is not in
the classpath,
the default behavior of JSecurity is broken.
IMO, we should either make a hard dependency on Ehcache or make
HashtableCacheManager the default cache manager.
I think it makes sense to fall back to HashtableCacheManager as the
default. It might also be worth considering taking a leaf out of
the
SLF4J book and having an adapter jar such as "ehcache-manager.jar"
that users can depend on or not.
Cheers,
Peter
