You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "Raif S. Naffah" <js...@naffah-raif.name> on 2009/01/05 08:58:12 UTC

JSecurity configuration documentation

hello there,

* besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter, is 
there any additional documentation that describes how to configure 
JSecurity?  if there is, a URL would be much appreciated.

* are there any plans, or would there be an interest, in providing a 
configuration API, based on a W3C Schema and xml-to-Java binding classes, 
generated from Apache XMLBeans for example?


cheers;
rsn


Re: JSecurity configuration documentation

Posted by Les Hazlewood <lh...@apache.org>.
On Tue, Jan 6, 2009 at 2:33 AM, Raif S. Naffah
<js...@naffah-raif.name>wrote:

> beanA = some.fully.qualified.ClassA
> > beanA.property1 = Hello World
> >
> > myBean = some.fully.qualified.Class
> > myBean.propertyA = $beanA
>
> ...so something similar to PropertyUtilsBean in Apache Commons BeanUtils.
> '


Exactly.  We use PropertyUtils under the hood, but we have to do more than
just what PU provides, for example, object references via '$' and some other
minor things.


> i was hoping for a document that describes the available/possible
> properties
> etc... of what can be configured more so than how it is configured.


Just as with PropertyUtils or Spring, that would be any Class's JavaDoc.
Any setter on any Class serves as the indicator of what can be injected.

is it safe then to assume that the javadoc of the above class describes all
> the possible options?


No - the JavaDoc in JSecurityFilter is just an example bean configuration
for filter chains and other things.  You could essentially put any class
instance declaration and configure its properties like any other bean.
Anything that BeanUtils supports.


> > It has been a desire of mine for a long time to maybe found another open
> > source project, say, "OGDL" that specified an "Object Graph Definition
> > Language" as a companion to OGNL.  It would be the most concise way to
> > configure any DI framework - Spring, Guice, whatever.
> > ...[edited]
>
> no thanks :-)  i'm more interested in configuration correctness than
> mechanisms, and de-coupling the configuration from the other life-cycle
> states of the objects/components.  for me a schema based xml offers the
> best
> guarantees hence the question.


Understood.  At the moment, pretty much everyone who wants that kind of
correctness, i.e. backing by an XML Schema definition, uses Spring or some
other XML bean configuration mechanism.

Currently the JSecurity team defers to those other more robust mechanisms
instead of writing our own, since they're all incredibly powerful already -
it sounds like quite a bit of work to provide what they do - bean injection,
managing lifecycles, circular dependency detection, etc.

My 'OGDL' idea was one for an alternate light-weight configuration mechanism
for people who didn't want XML or schema correctness.  If they want XML,
there are a ton of frameworks out there that provide bean configuration via
XML, including even, the JDK.

In any event, the JSecurityFilter supports a 'configClassName' init-param.
You can specify any fully-qualified class name implementation of the
Configuration interface (
http://www.jsecurity.org/api/org/jsecurity/config/Configuration.html).  The
JSecurityFilter will use the default no-arg constructor of that class and
then immediately acquire the SecurityManager instance. This allows you to
configure the SecurityManager however you wish in case one of our default
methods might not be suitable for you.

But then, if you'd like to contribute an XML mechanism that works, please
start another thread to discuss it.  I'm not sure if that's a road we want
to go down, but we're certainly open to your feedback and suggestions.

Best regards,

Les

Re: JSecurity configuration documentation

Posted by "Raif S. Naffah" <js...@naffah-raif.name>.
hello Lez,

thanks for your prompt reply!


On Tue January 6 2009 08:41:41 Les Hazlewood wrote:
> > * besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter,
> > is there any additional documentation that describes how to configure
> > JSecurity?  if there is, a URL would be much appreciated.
>
> Hi Raif,
>
> For .ini based configuration, not at the moment.
>
> At least for the purpose of this email, you can consider our text-based
> approach a rudimentary mechanism for dependency injection.  For example:
>
> beanA = some.fully.qualified.ClassA
> beanA.property1 = Hello World
>
> myBean = some.fully.qualified.Class
> myBean.propertyA = $beanA

...so something similar to PropertyUtilsBean in Apache Commons BeanUtils.  i 
was hoping for a document that describes the available/possible properties 
etc... of what can be configured more so than how it is configured.

is it safe then to assume that the javadoc of the above class describes all 
the possible options?


>  * are there any plans, or would there be an interest, in providing a
>
> > configuration API, based on a W3C Schema and xml-to-Java binding
> > classes, generated from Apache XMLBeans for example?
>
> There hasn't been any effort to move in that direction.  The
> configuration above (rudimentary .ini config) seems to be more desireable
> and agreeable to the majority of users.  A lot of us are kinda "XML'd
> out" :)  But if there is enough interest in the community for XML-based
> config, I'm sure we would probably support it.  Its just there hasn't
> been anyone asking for it...

noted.


> Best,
>
> Les
>
> P.S.  This is a little off topic but related to your first question. 
> Please ignore if you have no interest ;)
>
> It has been a desire of mine for a long time to maybe found another open
> source project, say, "OGDL" that specified an "Object Graph Definition
> Language" as a companion to OGNL.  It would be the most concise way to
> configure any DI framework - Spring, Guice, whatever.
> ...[edited]

no thanks :-)  i'm more interested in configuration correctness than 
mechanisms, and de-coupling the configuration from the other life-cycle 
states of the objects/components.  for me a schema based xml offers the best 
guarantees hence the question.


cheers;
rsn

Re: JSecurity configuration documentation

Posted by Les Hazlewood <lh...@apache.org>.
> * besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter, is
> there any additional documentation that describes how to configure
> JSecurity?  if there is, a URL would be much appreciated.


Hi Raif,

For .ini based configuration, not at the moment.

At least for the purpose of this email, you can consider our text-based
approach a rudimentary mechanism for dependency injection.  For example:

beanA = some.fully.qualified.ClassA
beanA.property1 = Hello World

myBean = some.fully.qualified.Class
myBean.propertyA = $beanA

 * are there any plans, or would there be an interest, in providing a

> configuration API, based on a W3C Schema and xml-to-Java binding classes,
> generated from Apache XMLBeans for example?


There hasn't been any effort to move in that direction.  The configuration
above (rudimentary .ini config) seems to be more desireable and agreeable to
the majority of users.  A lot of us are kinda "XML'd out" :)  But if there
is enough interest in the community for XML-based config, I'm sure we would
probably support it.  Its just there hasn't been anyone asking for it...

Best,

Les

P.S.  This is a little off topic but related to your first question.  Please
ignore if you have no interest ;)

It has been a desire of mine for a long time to maybe found another open
source project, say, "OGDL" that specified an "Object Graph Definition
Language" as a companion to OGNL.  It would be the most concise way to
configure any DI framework - Spring, Guice, whatever.

I wanted to have that as the text-based config used in the JSecurityFilter
and we could use a library that could parse the text and transform it into
an object graph.  The JSecurity SecurityManager is essentially an object
graph with the SecurityManager implementation as the root node.

This would be much nicer and easier to read than XML.  For example:

securityManager: some.fully.qualified.ClassName {
    property1:$someRef
    property2:$anotherRef
    property3: "Hello World"
}

I could see Spring configs using this syntax instead of XML.  Maybe a
OgdlApplicationContext.  I should write that :)