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 <[EMAIL PROTECTED]> 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 >
