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
