incubator-shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: Problematic first steps with JSecurity
Date Wed, 15 Oct 2008 18:01:58 GMT
Hi Grzegorz,

> perhaps I will add the required poms for
> simple applications, as this is probably not much work. Still it's good you
> have the main pom.xml file in the project.

Yep, we'd be very happy to have your pom contributions!  Please notify
this list if you have the opportunity to make them.

> 3. The "global" jsecurity setting for filters makes now sense for me. I even
> found the loginUrl property - it was inherited by FormAuthenticationFiler,
> what I haven't noticed before. I think I like this global setting more than
> variables, but obviously variable can be useful too.

Its nice that either option is there - you can choose what you prefer :)

> 4.Regarding default users settings - that's interesting. I found the
> properties file, it is actually called
> org\jsecurity\realm\text\ This can be
> useful for jumpstarting, but it should be also clearly explained that it is
> installed by deafult! Please at least update the QuickStart article on
> JSecurity page to mention this fact - I was really puzzled how it can work
> without defining users and roles somewhere!

Could you please open a Jira issue for this?

I've found that if its not in Jira, it might be forgotten!

> One thing is not clear for me: I undertand those default users are linked to
> some realm. How is this realm defined? How can I be sure it will not be
> active in production? I don't see any [realms] or so section in
> JSecurityFilter config.

The DefaultSecurityManager creates a Realm by default using this
failsafe file if you don't specify any Realms yourself.  It is only a
failsafe mechanism, so it would never be created/enabled in any
application where you set one or more of your own Realms.

If you have access to the source code, you can look at the
org.jsecurity.mgt.RealmSecurityManager abstract class (it is in the
parent class chain of DefaultSecurityManager), specifically the
ensureRealms() and createDefaultRealm() methods. These can be
overridden in a subclass if you prefer, or you can just inject your
own Realm (this should be done anyway) and the default won't be

Maybe this is something that can be discussed by the development team
before releasing 1.0 - to _not_ enable a default realm, as it might be
confusing than it helps, as was probably your case.  Please open a
Jira issue as an "Improvement" so we can discuss it further.

> And more generally: how do I turn off the default
> settings (e.g. turn off basic http authentication filter?)

Many default filters are created by default in a web environment, but
none of them are used unless you explicitly configure them to be used
in the [urls] section of the jsecurity configuration.  That is, they
are automatically in the available 'pool' ready to be used, but won't
be used unless you explicitly enable them in a url mapping.

> Recently I was trying to learn Spring Security, especially ACL
> functionality. I have even published my results here:
> - you may look at it in your free time. I will try to implement similar
> sample application in JSecurity now, and will let you know about results.

The write-up is really fantastic - very thorough and well done - nice
job!  I hope that your experience with JSecurity will be a little
better, and at the least, require much less effort than the Acegi
writeup took you.  Please keep us posted!



View raw message