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 Thu, 16 Oct 2008 22:49:31 GMT
Hi Grzegorz,

I just saw the issue you opened (JSEC-20), about
SecurityUtils.getSubject() returning null.  It should _never_ return
null, and if it is, that probably means there is an error in
configuration somewhere.

The JSecurityFilter in web.xml guarantees this will not occur.  I'm
assuming your using this filter?

I'm just confused as to how this could happen.  Could you give me a
little more explanation as to how you're seeing this?  Maybe some
JSecurity trace/debug output would be helpful.



On Wed, Oct 15, 2008 at 3:29 PM, Les Hazlewood <> wrote:
> P.S.  I've checked in some new annotations yesterday, so you'll
> probably want to work with an SVN checkout - not RC2 - so you can use
> them while you try things out.
> On Wed, Oct 15, 2008 at 2:01 PM, Les Hazlewood <> wrote:
>> 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
>> created.
>> 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!
>> Cheers,
>> Les

View raw message