Mailing-List: contact jsecurity-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jsecurity-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <44b57a610810151229l45035adeoaba90b01f27b86ad@mail.gmail.com>
Date: Wed, 15 Oct 2008 15:29:28 -0400
From: "Les Hazlewood" <les@hazlewood.com>
Sender: les.hazlewood@anjinllc.com
To: jsecurity-dev@incubator.apache.org
Subject: Re: Problematic first steps with JSecurity
In-Reply-To: <44b57a610810151101s8d24e8s428ee480ce587732@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1223643488404-1316205.post@n2.nabble.com>
	 <44b57a610810101321v1aa38b2by3ff83b802872fd5c@mail.gmail.com>
	 <1224080758761-1336981.post@n2.nabble.com>
	 <44b57a610810151101s8d24e8s428ee480ce587732@mail.gmail.com>

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 <les@hazlewood.com> 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\default-jsecurity-users.properties. 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?
> http://issues.apache.org/jira/browse/JSEC
>
> 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:
>> http://grzegorzborkowski.blogspot.com/2008/10/spring-security-acl-very-basic-tutorial.html
>> http://grzegorzborkowski.blogspot.com/2008/10/spring-security-acl-very-basic-tutorial.html
>> - 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
>