You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2010/01/21 18:12:32 UTC
[ANN] Upcoming enhanced Spring support
The upcoming Shiro 1.0 release will have improved Spring application
support, especially for Spring web applications.
In Shiro-enabled Spring web apps today, there was often a hybrid
configuration - you would usually define an INI-based Shiro Filter in
web.xml and configure it via INI mechanisms. But often you would
configure the SecurityManager and its dependencies (Realms, etc) in
applicationContext.xml. In Shiro 1.0, you will be able to configure
all of Shiro in your Spring files and only touch web.xml only when
setting up Shiro for the first time.
There are many benefits for Spring users when configuring Shiro
entirely in Spring instead of in web.xml:
1) Shiro configuration can live along side where you configure the
rest of your application - no need to flip back between web.xml and
spring files when making configuration changes.
2) Shiro configuration can leverage Spring-specific configuration
benefits, such as PropertyPlaceholderConfigurer for properties based
configuration at startup, spring-managed lifecycles (init-method,
destroy-method), circular dependency checks, and more.
3) Custom javax.servlet.Filters that you could use in Shiro's powerful
url-pattern-based filter chain definitions can also be defined in
Spring and acquired automatically at startup.
The current documentation for all of this is located here:
http://cwiki.apache.org/confluence/display/SHIRO/Spring
Please feel free to review and offer suggestions/improvements. The
mechanisms documented (using Spring's DelegatingFilterProxy and the
new ShiroFilterFactoryBean) have been tested and the two spring web
sample applications have been updated to use this approach.
Early adopters are encouraged to use this newer support before 1.0 is
released as there probably won't be any significant changes to this
mechanism before then. (SecurityManager configuration might be
simplified via a Spring FactoryBean as well, but that won't affect web
configuration).
Please give it a try and let us know what you think!
Best,
Les
Re: [ANN] Upcoming enhanced Spring support
Posted by Les Hazlewood <lh...@apache.org>.
Sounds good!
On Mon, Feb 8, 2010 at 12:59 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yeah we should, that's what I implied in the PS. I can take a look -
> I'll open another jira for it.
>
> Kalle
>
>
> On Mon, Feb 8, 2010 at 9:46 AM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm wondering - shouldn't we do this for all of our support modules then?
>>
>> On Mon, Feb 8, 2010 at 12:32 PM, Tauren Mills <yo...@gmail.com> wrote:
>>> Kalle,
>>> I see you already committed this change! Thanks for the prompt action. I
>>> agree that very few situations would not specify Spring dependency somewhere
>>> else.
>>> Tauren
>>>
>>> On Mon, Feb 8, 2010 at 8:41 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>
>>>> Hi Kalle,
>>>>
>>>> +1
>>>>
>>>> I think this is a good idea - I must be "having a case of the Mondays"
>>>> ;). Yes, almost everyone who uses shiro-spring integration will most
>>>> certainly specify their Spring dependency elsewhere.
>>>>
>>>> Cheers,
>>>>
>>>> Les
>>>>
>>>> On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>> > Yea, the problem originates from us depending on spring-all but many
>>>> > users likely depending on only those specific Spring libs they need,
>>>> > in which case artifact ids don't match and you end with duplicate libs
>>>> > in your classpath. We should mark Spring as scope provided, presumably
>>>> > people don't use shiro-spring as the end dependency to get Spring. If
>>>> > I don't hear otherwise, I'll create a JIRA and fix it.
>>>> >
>>>> > Kalle
>>>> >
>>>> > PS. Les, for commons-logging the situation is much the same. The
>>>> > proper way is to lobby the projects to mark common-logging as
>>>> > provided, but it's a more difficult problem to solve since there may
>>>> > not be any other end dependency for commons logging unless you
>>>> > provided one (either slf or commons-logging). We should evaluate all
>>>> > of our third-party dependencies and mark them as provided if at all
>>>> > possible - it's more difficult to go from compiled to provided than
>>>> > the other way around.
>>>> >
>>>> >
>>>> > On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org>
>>>> > wrote:
>>>> >> Hi Tauren,
>>>> >>
>>>> >> Yep, this is pretty customary in Maven poms as I understand it, but
>>>> >> I'd love to hear if there is a better way. I have to do this
>>>> >> regularly for any dependency that pulls in commons-logging - I have to
>>>> >> manually exclude it since I use SLF4J's version instead.
>>>> >>
>>>> >> If there's a better way, I'm all ears!
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Les
>>>> >>
>>>> >> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com>
>>>> >> wrote:
>>>> >>> Can something be done to make Shiro support either Spring 2.5.6 or
>>>> >>> Spring
>>>> >>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found
>>>> >>> that
>>>> >>> Shiro was including spring 2.5.6 as a dependency. I had to manually
>>>> >>> exclude
>>>> >>> it in my pom.
>>>> >>> <dependency>
>>>> >>> <groupId>org.apache.shiro</groupId>
>>>> >>> <artifactId>shiro-spring</artifactId>
>>>> >>> <version>${shiro.version}</version>
>>>> >>> <exclusions>
>>>> >>> <exclusion>
>>>> >>> <groupId>org.springframework</groupId>
>>>> >>> <artifactId>spring</artifactId>
>>>> >>> </exclusion>
>>>> >>> </exclusions>
>>>> >>> </dependency>
>>>> >>> The good news is that this doesn't seem to have caused any problems
>>>> >>> for my
>>>> >>> application. I saw another project that manages to support both
>>>> >>> versions in
>>>> >>> their pom, but can't remember which project it was or how they did it.
>>>> >>> I'll
>>>> >>> try to find it if it would help.
>>>> >>> Of course I'm open to suggestions if there is a better way to deal
>>>> >>> with
>>>> >>> this.
>>>> >>> Thanks,
>>>> >>> Tauren
>>>> >>>
>>>> >>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>>>> >>>>
>>>> >>>> ah, the question wasnt how to check, but how to configure.
>>>> >>>> I mean how do u abandon the shiro.ini roles & permissions mechanism
>>>> >>>> for
>>>> >>>> TextConfigurationRealm etc and model it in spring instead.
>>>> >>>> I thought in a previous post you mentioned this should be done.
>>>> >>>>
>>>> >>>> re the useage though I'm really keen for an aop solution, and an xml
>>>> >>>> element something like this:
>>>> >>>> <shiro:requires permissions="user:edit"/>
>>>> >>>> that I could just drop into any spring bean would be great. far
>>>> >>>> better for
>>>> >>>> me than annotations.
>>>> >>>>
>>>> >>>> Cheers
>>>> >>>> Jason.
>>>> >>>>
>>>> >>>>
>>>> >>>> Les Hazlewood wrote:
>>>> >>>>>
>>>> >>>>> Hi Jason,
>>>> >>>>>
>>>> >>>>> What do you mean by 'configure permissions' exactly? Typically
>>>> >>>>> permission checks in standalone applications are done by explicitly
>>>> >>>>> checking (subject.isPermitted(blah)) or using Shiro's
>>>> >>>>> @RequiresPermissions annotation.
>>>> >>>>>
>>>> >>>>> Regards,
>>>> >>>>>
>>>> >>>>> Les
>>>> >>>>>
>>>> >>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott
>>>> >>>>> <ja...@hardlight.com.au>
>>>> >>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> thanks!
>>>> >>>>>> now how do I configure permissions etc in spring for a standalone
>>>> >>>>>> app?
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Les Hazlewood wrote:
>>>> >>>>>>>
>>>> >>>>>>> The upcoming Shiro 1.0 release will have improved Spring
>>>> >>>>>>> application
>>>> >>>>>>> support, especially for Spring web applications.
>>>> >>>>>>>
>>>> >>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>>> >>>>>>> configuration - you would usually define an INI-based Shiro Filter
>>>> >>>>>>> in
>>>> >>>>>>> web.xml and configure it via INI mechanisms. But often you would
>>>> >>>>>>> configure the SecurityManager and its dependencies (Realms, etc)
>>>> >>>>>>> in
>>>> >>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to
>>>> >>>>>>> configure
>>>> >>>>>>> all of Shiro in your Spring files and only touch web.xml only when
>>>> >>>>>>> setting up Shiro for the first time.
>>>> >>>>>>>
>>>> >>>>>>> There are many benefits for Spring users when configuring Shiro
>>>> >>>>>>> entirely in Spring instead of in web.xml:
>>>> >>>>>>>
>>>> >>>>>>> 1) Shiro configuration can live along side where you configure the
>>>> >>>>>>> rest of your application - no need to flip back between web.xml
>>>> >>>>>>> and
>>>> >>>>>>> spring files when making configuration changes.
>>>> >>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>>> >>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties
>>>> >>>>>>> based
>>>> >>>>>>> configuration at startup, spring-managed lifecycles (init-method,
>>>> >>>>>>> destroy-method), circular dependency checks, and more.
>>>> >>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's
>>>> >>>>>>> powerful
>>>> >>>>>>> url-pattern-based filter chain definitions can also be defined in
>>>> >>>>>>> Spring and acquired automatically at startup.
>>>> >>>>>>>
>>>> >>>>>>> The current documentation for all of this is located here:
>>>> >>>>>>>
>>>> >>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>> >>>>>>>
>>>> >>>>>>> Please feel free to review and offer suggestions/improvements.
>>>> >>>>>>> The
>>>> >>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and
>>>> >>>>>>> the
>>>> >>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring
>>>> >>>>>>> web
>>>> >>>>>>> sample applications have been updated to use this approach.
>>>> >>>>>>>
>>>> >>>>>>> Early adopters are encouraged to use this newer support before 1.0
>>>> >>>>>>> is
>>>> >>>>>>> released as there probably won't be any significant changes to
>>>> >>>>>>> this
>>>> >>>>>>> mechanism before then. (SecurityManager configuration might be
>>>> >>>>>>> simplified via a Spring FactoryBean as well, but that won't affect
>>>> >>>>>>> web
>>>> >>>>>>> configuration).
>>>> >>>>>>>
>>>> >>>>>>> Please give it a try and let us know what you think!
>>>> >>>>>>>
>>>> >>>>>>> Best,
>>>> >>>>>>>
>>>> >>>>>>> Les
>>>> >>>>>>>
>>>> >>>>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>
>>>
>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Kalle Korhonen <ka...@gmail.com>.
Yeah we should, that's what I implied in the PS. I can take a look -
I'll open another jira for it.
Kalle
On Mon, Feb 8, 2010 at 9:46 AM, Les Hazlewood <lh...@apache.org> wrote:
> I'm wondering - shouldn't we do this for all of our support modules then?
>
> On Mon, Feb 8, 2010 at 12:32 PM, Tauren Mills <yo...@gmail.com> wrote:
>> Kalle,
>> I see you already committed this change! Thanks for the prompt action. I
>> agree that very few situations would not specify Spring dependency somewhere
>> else.
>> Tauren
>>
>> On Mon, Feb 8, 2010 at 8:41 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>
>>> Hi Kalle,
>>>
>>> +1
>>>
>>> I think this is a good idea - I must be "having a case of the Mondays"
>>> ;). Yes, almost everyone who uses shiro-spring integration will most
>>> certainly specify their Spring dependency elsewhere.
>>>
>>> Cheers,
>>>
>>> Les
>>>
>>> On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>> > Yea, the problem originates from us depending on spring-all but many
>>> > users likely depending on only those specific Spring libs they need,
>>> > in which case artifact ids don't match and you end with duplicate libs
>>> > in your classpath. We should mark Spring as scope provided, presumably
>>> > people don't use shiro-spring as the end dependency to get Spring. If
>>> > I don't hear otherwise, I'll create a JIRA and fix it.
>>> >
>>> > Kalle
>>> >
>>> > PS. Les, for commons-logging the situation is much the same. The
>>> > proper way is to lobby the projects to mark common-logging as
>>> > provided, but it's a more difficult problem to solve since there may
>>> > not be any other end dependency for commons logging unless you
>>> > provided one (either slf or commons-logging). We should evaluate all
>>> > of our third-party dependencies and mark them as provided if at all
>>> > possible - it's more difficult to go from compiled to provided than
>>> > the other way around.
>>> >
>>> >
>>> > On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org>
>>> > wrote:
>>> >> Hi Tauren,
>>> >>
>>> >> Yep, this is pretty customary in Maven poms as I understand it, but
>>> >> I'd love to hear if there is a better way. I have to do this
>>> >> regularly for any dependency that pulls in commons-logging - I have to
>>> >> manually exclude it since I use SLF4J's version instead.
>>> >>
>>> >> If there's a better way, I'm all ears!
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Les
>>> >>
>>> >> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com>
>>> >> wrote:
>>> >>> Can something be done to make Shiro support either Spring 2.5.6 or
>>> >>> Spring
>>> >>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found
>>> >>> that
>>> >>> Shiro was including spring 2.5.6 as a dependency. I had to manually
>>> >>> exclude
>>> >>> it in my pom.
>>> >>> <dependency>
>>> >>> <groupId>org.apache.shiro</groupId>
>>> >>> <artifactId>shiro-spring</artifactId>
>>> >>> <version>${shiro.version}</version>
>>> >>> <exclusions>
>>> >>> <exclusion>
>>> >>> <groupId>org.springframework</groupId>
>>> >>> <artifactId>spring</artifactId>
>>> >>> </exclusion>
>>> >>> </exclusions>
>>> >>> </dependency>
>>> >>> The good news is that this doesn't seem to have caused any problems
>>> >>> for my
>>> >>> application. I saw another project that manages to support both
>>> >>> versions in
>>> >>> their pom, but can't remember which project it was or how they did it.
>>> >>> I'll
>>> >>> try to find it if it would help.
>>> >>> Of course I'm open to suggestions if there is a better way to deal
>>> >>> with
>>> >>> this.
>>> >>> Thanks,
>>> >>> Tauren
>>> >>>
>>> >>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>>> >>>>
>>> >>>> ah, the question wasnt how to check, but how to configure.
>>> >>>> I mean how do u abandon the shiro.ini roles & permissions mechanism
>>> >>>> for
>>> >>>> TextConfigurationRealm etc and model it in spring instead.
>>> >>>> I thought in a previous post you mentioned this should be done.
>>> >>>>
>>> >>>> re the useage though I'm really keen for an aop solution, and an xml
>>> >>>> element something like this:
>>> >>>> <shiro:requires permissions="user:edit"/>
>>> >>>> that I could just drop into any spring bean would be great. far
>>> >>>> better for
>>> >>>> me than annotations.
>>> >>>>
>>> >>>> Cheers
>>> >>>> Jason.
>>> >>>>
>>> >>>>
>>> >>>> Les Hazlewood wrote:
>>> >>>>>
>>> >>>>> Hi Jason,
>>> >>>>>
>>> >>>>> What do you mean by 'configure permissions' exactly? Typically
>>> >>>>> permission checks in standalone applications are done by explicitly
>>> >>>>> checking (subject.isPermitted(blah)) or using Shiro's
>>> >>>>> @RequiresPermissions annotation.
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>>
>>> >>>>> Les
>>> >>>>>
>>> >>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott
>>> >>>>> <ja...@hardlight.com.au>
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>> thanks!
>>> >>>>>> now how do I configure permissions etc in spring for a standalone
>>> >>>>>> app?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Les Hazlewood wrote:
>>> >>>>>>>
>>> >>>>>>> The upcoming Shiro 1.0 release will have improved Spring
>>> >>>>>>> application
>>> >>>>>>> support, especially for Spring web applications.
>>> >>>>>>>
>>> >>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>> >>>>>>> configuration - you would usually define an INI-based Shiro Filter
>>> >>>>>>> in
>>> >>>>>>> web.xml and configure it via INI mechanisms. But often you would
>>> >>>>>>> configure the SecurityManager and its dependencies (Realms, etc)
>>> >>>>>>> in
>>> >>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to
>>> >>>>>>> configure
>>> >>>>>>> all of Shiro in your Spring files and only touch web.xml only when
>>> >>>>>>> setting up Shiro for the first time.
>>> >>>>>>>
>>> >>>>>>> There are many benefits for Spring users when configuring Shiro
>>> >>>>>>> entirely in Spring instead of in web.xml:
>>> >>>>>>>
>>> >>>>>>> 1) Shiro configuration can live along side where you configure the
>>> >>>>>>> rest of your application - no need to flip back between web.xml
>>> >>>>>>> and
>>> >>>>>>> spring files when making configuration changes.
>>> >>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>> >>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties
>>> >>>>>>> based
>>> >>>>>>> configuration at startup, spring-managed lifecycles (init-method,
>>> >>>>>>> destroy-method), circular dependency checks, and more.
>>> >>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's
>>> >>>>>>> powerful
>>> >>>>>>> url-pattern-based filter chain definitions can also be defined in
>>> >>>>>>> Spring and acquired automatically at startup.
>>> >>>>>>>
>>> >>>>>>> The current documentation for all of this is located here:
>>> >>>>>>>
>>> >>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>> >>>>>>>
>>> >>>>>>> Please feel free to review and offer suggestions/improvements.
>>> >>>>>>> The
>>> >>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and
>>> >>>>>>> the
>>> >>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring
>>> >>>>>>> web
>>> >>>>>>> sample applications have been updated to use this approach.
>>> >>>>>>>
>>> >>>>>>> Early adopters are encouraged to use this newer support before 1.0
>>> >>>>>>> is
>>> >>>>>>> released as there probably won't be any significant changes to
>>> >>>>>>> this
>>> >>>>>>> mechanism before then. (SecurityManager configuration might be
>>> >>>>>>> simplified via a Spring FactoryBean as well, but that won't affect
>>> >>>>>>> web
>>> >>>>>>> configuration).
>>> >>>>>>>
>>> >>>>>>> Please give it a try and let us know what you think!
>>> >>>>>>>
>>> >>>>>>> Best,
>>> >>>>>>>
>>> >>>>>>> Les
>>> >>>>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>
>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Les Hazlewood <lh...@apache.org>.
I'm wondering - shouldn't we do this for all of our support modules then?
On Mon, Feb 8, 2010 at 12:32 PM, Tauren Mills <yo...@gmail.com> wrote:
> Kalle,
> I see you already committed this change! Thanks for the prompt action. I
> agree that very few situations would not specify Spring dependency somewhere
> else.
> Tauren
>
> On Mon, Feb 8, 2010 at 8:41 AM, Les Hazlewood <lh...@apache.org> wrote:
>>
>> Hi Kalle,
>>
>> +1
>>
>> I think this is a good idea - I must be "having a case of the Mondays"
>> ;). Yes, almost everyone who uses shiro-spring integration will most
>> certainly specify their Spring dependency elsewhere.
>>
>> Cheers,
>>
>> Les
>>
>> On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>> > Yea, the problem originates from us depending on spring-all but many
>> > users likely depending on only those specific Spring libs they need,
>> > in which case artifact ids don't match and you end with duplicate libs
>> > in your classpath. We should mark Spring as scope provided, presumably
>> > people don't use shiro-spring as the end dependency to get Spring. If
>> > I don't hear otherwise, I'll create a JIRA and fix it.
>> >
>> > Kalle
>> >
>> > PS. Les, for commons-logging the situation is much the same. The
>> > proper way is to lobby the projects to mark common-logging as
>> > provided, but it's a more difficult problem to solve since there may
>> > not be any other end dependency for commons logging unless you
>> > provided one (either slf or commons-logging). We should evaluate all
>> > of our third-party dependencies and mark them as provided if at all
>> > possible - it's more difficult to go from compiled to provided than
>> > the other way around.
>> >
>> >
>> > On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org>
>> > wrote:
>> >> Hi Tauren,
>> >>
>> >> Yep, this is pretty customary in Maven poms as I understand it, but
>> >> I'd love to hear if there is a better way. I have to do this
>> >> regularly for any dependency that pulls in commons-logging - I have to
>> >> manually exclude it since I use SLF4J's version instead.
>> >>
>> >> If there's a better way, I'm all ears!
>> >>
>> >> Cheers,
>> >>
>> >> Les
>> >>
>> >> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com>
>> >> wrote:
>> >>> Can something be done to make Shiro support either Spring 2.5.6 or
>> >>> Spring
>> >>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found
>> >>> that
>> >>> Shiro was including spring 2.5.6 as a dependency. I had to manually
>> >>> exclude
>> >>> it in my pom.
>> >>> <dependency>
>> >>> <groupId>org.apache.shiro</groupId>
>> >>> <artifactId>shiro-spring</artifactId>
>> >>> <version>${shiro.version}</version>
>> >>> <exclusions>
>> >>> <exclusion>
>> >>> <groupId>org.springframework</groupId>
>> >>> <artifactId>spring</artifactId>
>> >>> </exclusion>
>> >>> </exclusions>
>> >>> </dependency>
>> >>> The good news is that this doesn't seem to have caused any problems
>> >>> for my
>> >>> application. I saw another project that manages to support both
>> >>> versions in
>> >>> their pom, but can't remember which project it was or how they did it.
>> >>> I'll
>> >>> try to find it if it would help.
>> >>> Of course I'm open to suggestions if there is a better way to deal
>> >>> with
>> >>> this.
>> >>> Thanks,
>> >>> Tauren
>> >>>
>> >>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>> >>>>
>> >>>> ah, the question wasnt how to check, but how to configure.
>> >>>> I mean how do u abandon the shiro.ini roles & permissions mechanism
>> >>>> for
>> >>>> TextConfigurationRealm etc and model it in spring instead.
>> >>>> I thought in a previous post you mentioned this should be done.
>> >>>>
>> >>>> re the useage though I'm really keen for an aop solution, and an xml
>> >>>> element something like this:
>> >>>> <shiro:requires permissions="user:edit"/>
>> >>>> that I could just drop into any spring bean would be great. far
>> >>>> better for
>> >>>> me than annotations.
>> >>>>
>> >>>> Cheers
>> >>>> Jason.
>> >>>>
>> >>>>
>> >>>> Les Hazlewood wrote:
>> >>>>>
>> >>>>> Hi Jason,
>> >>>>>
>> >>>>> What do you mean by 'configure permissions' exactly? Typically
>> >>>>> permission checks in standalone applications are done by explicitly
>> >>>>> checking (subject.isPermitted(blah)) or using Shiro's
>> >>>>> @RequiresPermissions annotation.
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> Les
>> >>>>>
>> >>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott
>> >>>>> <ja...@hardlight.com.au>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> thanks!
>> >>>>>> now how do I configure permissions etc in spring for a standalone
>> >>>>>> app?
>> >>>>>>
>> >>>>>>
>> >>>>>> Les Hazlewood wrote:
>> >>>>>>>
>> >>>>>>> The upcoming Shiro 1.0 release will have improved Spring
>> >>>>>>> application
>> >>>>>>> support, especially for Spring web applications.
>> >>>>>>>
>> >>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>> >>>>>>> configuration - you would usually define an INI-based Shiro Filter
>> >>>>>>> in
>> >>>>>>> web.xml and configure it via INI mechanisms. But often you would
>> >>>>>>> configure the SecurityManager and its dependencies (Realms, etc)
>> >>>>>>> in
>> >>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to
>> >>>>>>> configure
>> >>>>>>> all of Shiro in your Spring files and only touch web.xml only when
>> >>>>>>> setting up Shiro for the first time.
>> >>>>>>>
>> >>>>>>> There are many benefits for Spring users when configuring Shiro
>> >>>>>>> entirely in Spring instead of in web.xml:
>> >>>>>>>
>> >>>>>>> 1) Shiro configuration can live along side where you configure the
>> >>>>>>> rest of your application - no need to flip back between web.xml
>> >>>>>>> and
>> >>>>>>> spring files when making configuration changes.
>> >>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>> >>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties
>> >>>>>>> based
>> >>>>>>> configuration at startup, spring-managed lifecycles (init-method,
>> >>>>>>> destroy-method), circular dependency checks, and more.
>> >>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's
>> >>>>>>> powerful
>> >>>>>>> url-pattern-based filter chain definitions can also be defined in
>> >>>>>>> Spring and acquired automatically at startup.
>> >>>>>>>
>> >>>>>>> The current documentation for all of this is located here:
>> >>>>>>>
>> >>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>> >>>>>>>
>> >>>>>>> Please feel free to review and offer suggestions/improvements.
>> >>>>>>> The
>> >>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and
>> >>>>>>> the
>> >>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring
>> >>>>>>> web
>> >>>>>>> sample applications have been updated to use this approach.
>> >>>>>>>
>> >>>>>>> Early adopters are encouraged to use this newer support before 1.0
>> >>>>>>> is
>> >>>>>>> released as there probably won't be any significant changes to
>> >>>>>>> this
>> >>>>>>> mechanism before then. (SecurityManager configuration might be
>> >>>>>>> simplified via a Spring FactoryBean as well, but that won't affect
>> >>>>>>> web
>> >>>>>>> configuration).
>> >>>>>>>
>> >>>>>>> Please give it a try and let us know what you think!
>> >>>>>>>
>> >>>>>>> Best,
>> >>>>>>>
>> >>>>>>> Les
>> >>>>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>> >
>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Tauren Mills <yo...@gmail.com>.
Kalle,
I see you already committed this change! Thanks for the prompt action. I
agree that very few situations would not specify Spring dependency somewhere
else.
Tauren
On Mon, Feb 8, 2010 at 8:41 AM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Kalle,
>
> +1
>
> I think this is a good idea - I must be "having a case of the Mondays"
> ;). Yes, almost everyone who uses shiro-spring integration will most
> certainly specify their Spring dependency elsewhere.
>
> Cheers,
>
> Les
>
> On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen
> <ka...@gmail.com> wrote:
> > Yea, the problem originates from us depending on spring-all but many
> > users likely depending on only those specific Spring libs they need,
> > in which case artifact ids don't match and you end with duplicate libs
> > in your classpath. We should mark Spring as scope provided, presumably
> > people don't use shiro-spring as the end dependency to get Spring. If
> > I don't hear otherwise, I'll create a JIRA and fix it.
> >
> > Kalle
> >
> > PS. Les, for commons-logging the situation is much the same. The
> > proper way is to lobby the projects to mark common-logging as
> > provided, but it's a more difficult problem to solve since there may
> > not be any other end dependency for commons logging unless you
> > provided one (either slf or commons-logging). We should evaluate all
> > of our third-party dependencies and mark them as provided if at all
> > possible - it's more difficult to go from compiled to provided than
> > the other way around.
> >
> >
> > On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org>
> wrote:
> >> Hi Tauren,
> >>
> >> Yep, this is pretty customary in Maven poms as I understand it, but
> >> I'd love to hear if there is a better way. I have to do this
> >> regularly for any dependency that pulls in commons-logging - I have to
> >> manually exclude it since I use SLF4J's version instead.
> >>
> >> If there's a better way, I'm all ears!
> >>
> >> Cheers,
> >>
> >> Les
> >>
> >> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com>
> wrote:
> >>> Can something be done to make Shiro support either Spring 2.5.6 or
> Spring
> >>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found
> that
> >>> Shiro was including spring 2.5.6 as a dependency. I had to manually
> exclude
> >>> it in my pom.
> >>> <dependency>
> >>> <groupId>org.apache.shiro</groupId>
> >>> <artifactId>shiro-spring</artifactId>
> >>> <version>${shiro.version}</version>
> >>> <exclusions>
> >>> <exclusion>
> >>> <groupId>org.springframework</groupId>
> >>> <artifactId>spring</artifactId>
> >>> </exclusion>
> >>> </exclusions>
> >>> </dependency>
> >>> The good news is that this doesn't seem to have caused any problems for
> my
> >>> application. I saw another project that manages to support both
> versions in
> >>> their pom, but can't remember which project it was or how they did it.
> I'll
> >>> try to find it if it would help.
> >>> Of course I'm open to suggestions if there is a better way to deal with
> >>> this.
> >>> Thanks,
> >>> Tauren
> >>>
> >>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
> >>>>
> >>>> ah, the question wasnt how to check, but how to configure.
> >>>> I mean how do u abandon the shiro.ini roles & permissions mechanism
> for
> >>>> TextConfigurationRealm etc and model it in spring instead.
> >>>> I thought in a previous post you mentioned this should be done.
> >>>>
> >>>> re the useage though I'm really keen for an aop solution, and an xml
> >>>> element something like this:
> >>>> <shiro:requires permissions="user:edit"/>
> >>>> that I could just drop into any spring bean would be great. far better
> for
> >>>> me than annotations.
> >>>>
> >>>> Cheers
> >>>> Jason.
> >>>>
> >>>>
> >>>> Les Hazlewood wrote:
> >>>>>
> >>>>> Hi Jason,
> >>>>>
> >>>>> What do you mean by 'configure permissions' exactly? Typically
> >>>>> permission checks in standalone applications are done by explicitly
> >>>>> checking (subject.isPermitted(blah)) or using Shiro's
> >>>>> @RequiresPermissions annotation.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Les
> >>>>>
> >>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <
> jason@hardlight.com.au>
> >>>>> wrote:
> >>>>>>
> >>>>>> thanks!
> >>>>>> now how do I configure permissions etc in spring for a standalone
> app?
> >>>>>>
> >>>>>>
> >>>>>> Les Hazlewood wrote:
> >>>>>>>
> >>>>>>> The upcoming Shiro 1.0 release will have improved Spring
> application
> >>>>>>> support, especially for Spring web applications.
> >>>>>>>
> >>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
> >>>>>>> configuration - you would usually define an INI-based Shiro Filter
> in
> >>>>>>> web.xml and configure it via INI mechanisms. But often you would
> >>>>>>> configure the SecurityManager and its dependencies (Realms, etc) in
> >>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to
> configure
> >>>>>>> all of Shiro in your Spring files and only touch web.xml only when
> >>>>>>> setting up Shiro for the first time.
> >>>>>>>
> >>>>>>> There are many benefits for Spring users when configuring Shiro
> >>>>>>> entirely in Spring instead of in web.xml:
> >>>>>>>
> >>>>>>> 1) Shiro configuration can live along side where you configure the
> >>>>>>> rest of your application - no need to flip back between web.xml and
> >>>>>>> spring files when making configuration changes.
> >>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
> >>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties
> based
> >>>>>>> configuration at startup, spring-managed lifecycles (init-method,
> >>>>>>> destroy-method), circular dependency checks, and more.
> >>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's
> powerful
> >>>>>>> url-pattern-based filter chain definitions can also be defined in
> >>>>>>> Spring and acquired automatically at startup.
> >>>>>>>
> >>>>>>> The current documentation for all of this is located here:
> >>>>>>>
> >>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
> >>>>>>>
> >>>>>>> Please feel free to review and offer suggestions/improvements. The
> >>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
> >>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring web
> >>>>>>> sample applications have been updated to use this approach.
> >>>>>>>
> >>>>>>> Early adopters are encouraged to use this newer support before 1.0
> is
> >>>>>>> released as there probably won't be any significant changes to this
> >>>>>>> mechanism before then. (SecurityManager configuration might be
> >>>>>>> simplified via a Spring FactoryBean as well, but that won't affect
> web
> >>>>>>> configuration).
> >>>>>>>
> >>>>>>> Please give it a try and let us know what you think!
> >>>>>>>
> >>>>>>> Best,
> >>>>>>>
> >>>>>>> Les
> >>>>>>>
> >>>>>
> >>>
> >>>
> >>
> >
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Les Hazlewood <lh...@apache.org>.
Hi Kalle,
+1
I think this is a good idea - I must be "having a case of the Mondays"
;). Yes, almost everyone who uses shiro-spring integration will most
certainly specify their Spring dependency elsewhere.
Cheers,
Les
On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yea, the problem originates from us depending on spring-all but many
> users likely depending on only those specific Spring libs they need,
> in which case artifact ids don't match and you end with duplicate libs
> in your classpath. We should mark Spring as scope provided, presumably
> people don't use shiro-spring as the end dependency to get Spring. If
> I don't hear otherwise, I'll create a JIRA and fix it.
>
> Kalle
>
> PS. Les, for commons-logging the situation is much the same. The
> proper way is to lobby the projects to mark common-logging as
> provided, but it's a more difficult problem to solve since there may
> not be any other end dependency for commons logging unless you
> provided one (either slf or commons-logging). We should evaluate all
> of our third-party dependencies and mark them as provided if at all
> possible - it's more difficult to go from compiled to provided than
> the other way around.
>
>
> On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org> wrote:
>> Hi Tauren,
>>
>> Yep, this is pretty customary in Maven poms as I understand it, but
>> I'd love to hear if there is a better way. I have to do this
>> regularly for any dependency that pulls in commons-logging - I have to
>> manually exclude it since I use SLF4J's version instead.
>>
>> If there's a better way, I'm all ears!
>>
>> Cheers,
>>
>> Les
>>
>> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com> wrote:
>>> Can something be done to make Shiro support either Spring 2.5.6 or Spring
>>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found that
>>> Shiro was including spring 2.5.6 as a dependency. I had to manually exclude
>>> it in my pom.
>>> <dependency>
>>> <groupId>org.apache.shiro</groupId>
>>> <artifactId>shiro-spring</artifactId>
>>> <version>${shiro.version}</version>
>>> <exclusions>
>>> <exclusion>
>>> <groupId>org.springframework</groupId>
>>> <artifactId>spring</artifactId>
>>> </exclusion>
>>> </exclusions>
>>> </dependency>
>>> The good news is that this doesn't seem to have caused any problems for my
>>> application. I saw another project that manages to support both versions in
>>> their pom, but can't remember which project it was or how they did it. I'll
>>> try to find it if it would help.
>>> Of course I'm open to suggestions if there is a better way to deal with
>>> this.
>>> Thanks,
>>> Tauren
>>>
>>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>>>>
>>>> ah, the question wasnt how to check, but how to configure.
>>>> I mean how do u abandon the shiro.ini roles & permissions mechanism for
>>>> TextConfigurationRealm etc and model it in spring instead.
>>>> I thought in a previous post you mentioned this should be done.
>>>>
>>>> re the useage though I'm really keen for an aop solution, and an xml
>>>> element something like this:
>>>> <shiro:requires permissions="user:edit"/>
>>>> that I could just drop into any spring bean would be great. far better for
>>>> me than annotations.
>>>>
>>>> Cheers
>>>> Jason.
>>>>
>>>>
>>>> Les Hazlewood wrote:
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> What do you mean by 'configure permissions' exactly? Typically
>>>>> permission checks in standalone applications are done by explicitly
>>>>> checking (subject.isPermitted(blah)) or using Shiro's
>>>>> @RequiresPermissions annotation.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Les
>>>>>
>>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au>
>>>>> wrote:
>>>>>>
>>>>>> thanks!
>>>>>> now how do I configure permissions etc in spring for a standalone app?
>>>>>>
>>>>>>
>>>>>> Les Hazlewood wrote:
>>>>>>>
>>>>>>> The upcoming Shiro 1.0 release will have improved Spring application
>>>>>>> support, especially for Spring web applications.
>>>>>>>
>>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>>>>>> configuration - you would usually define an INI-based Shiro Filter in
>>>>>>> web.xml and configure it via INI mechanisms. But often you would
>>>>>>> configure the SecurityManager and its dependencies (Realms, etc) in
>>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>>>>>>> all of Shiro in your Spring files and only touch web.xml only when
>>>>>>> setting up Shiro for the first time.
>>>>>>>
>>>>>>> There are many benefits for Spring users when configuring Shiro
>>>>>>> entirely in Spring instead of in web.xml:
>>>>>>>
>>>>>>> 1) Shiro configuration can live along side where you configure the
>>>>>>> rest of your application - no need to flip back between web.xml and
>>>>>>> spring files when making configuration changes.
>>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties based
>>>>>>> configuration at startup, spring-managed lifecycles (init-method,
>>>>>>> destroy-method), circular dependency checks, and more.
>>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>>>>>>> url-pattern-based filter chain definitions can also be defined in
>>>>>>> Spring and acquired automatically at startup.
>>>>>>>
>>>>>>> The current documentation for all of this is located here:
>>>>>>>
>>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>>>>>
>>>>>>> Please feel free to review and offer suggestions/improvements. The
>>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring web
>>>>>>> sample applications have been updated to use this approach.
>>>>>>>
>>>>>>> Early adopters are encouraged to use this newer support before 1.0 is
>>>>>>> released as there probably won't be any significant changes to this
>>>>>>> mechanism before then. (SecurityManager configuration might be
>>>>>>> simplified via a Spring FactoryBean as well, but that won't affect web
>>>>>>> configuration).
>>>>>>>
>>>>>>> Please give it a try and let us know what you think!
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>
>>>
>>>
>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Kalle Korhonen <ka...@gmail.com>.
Yea, the problem originates from us depending on spring-all but many
users likely depending on only those specific Spring libs they need,
in which case artifact ids don't match and you end with duplicate libs
in your classpath. We should mark Spring as scope provided, presumably
people don't use shiro-spring as the end dependency to get Spring. If
I don't hear otherwise, I'll create a JIRA and fix it.
Kalle
PS. Les, for commons-logging the situation is much the same. The
proper way is to lobby the projects to mark common-logging as
provided, but it's a more difficult problem to solve since there may
not be any other end dependency for commons logging unless you
provided one (either slf or commons-logging). We should evaluate all
of our third-party dependencies and mark them as provided if at all
possible - it's more difficult to go from compiled to provided than
the other way around.
On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Tauren,
>
> Yep, this is pretty customary in Maven poms as I understand it, but
> I'd love to hear if there is a better way. I have to do this
> regularly for any dependency that pulls in commons-logging - I have to
> manually exclude it since I use SLF4J's version instead.
>
> If there's a better way, I'm all ears!
>
> Cheers,
>
> Les
>
> On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com> wrote:
>> Can something be done to make Shiro support either Spring 2.5.6 or Spring
>> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found that
>> Shiro was including spring 2.5.6 as a dependency. I had to manually exclude
>> it in my pom.
>> <dependency>
>> <groupId>org.apache.shiro</groupId>
>> <artifactId>shiro-spring</artifactId>
>> <version>${shiro.version}</version>
>> <exclusions>
>> <exclusion>
>> <groupId>org.springframework</groupId>
>> <artifactId>spring</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>> The good news is that this doesn't seem to have caused any problems for my
>> application. I saw another project that manages to support both versions in
>> their pom, but can't remember which project it was or how they did it. I'll
>> try to find it if it would help.
>> Of course I'm open to suggestions if there is a better way to deal with
>> this.
>> Thanks,
>> Tauren
>>
>> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>>>
>>> ah, the question wasnt how to check, but how to configure.
>>> I mean how do u abandon the shiro.ini roles & permissions mechanism for
>>> TextConfigurationRealm etc and model it in spring instead.
>>> I thought in a previous post you mentioned this should be done.
>>>
>>> re the useage though I'm really keen for an aop solution, and an xml
>>> element something like this:
>>> <shiro:requires permissions="user:edit"/>
>>> that I could just drop into any spring bean would be great. far better for
>>> me than annotations.
>>>
>>> Cheers
>>> Jason.
>>>
>>>
>>> Les Hazlewood wrote:
>>>>
>>>> Hi Jason,
>>>>
>>>> What do you mean by 'configure permissions' exactly? Typically
>>>> permission checks in standalone applications are done by explicitly
>>>> checking (subject.isPermitted(blah)) or using Shiro's
>>>> @RequiresPermissions annotation.
>>>>
>>>> Regards,
>>>>
>>>> Les
>>>>
>>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au>
>>>> wrote:
>>>>>
>>>>> thanks!
>>>>> now how do I configure permissions etc in spring for a standalone app?
>>>>>
>>>>>
>>>>> Les Hazlewood wrote:
>>>>>>
>>>>>> The upcoming Shiro 1.0 release will have improved Spring application
>>>>>> support, especially for Spring web applications.
>>>>>>
>>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>>>>> configuration - you would usually define an INI-based Shiro Filter in
>>>>>> web.xml and configure it via INI mechanisms. But often you would
>>>>>> configure the SecurityManager and its dependencies (Realms, etc) in
>>>>>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>>>>>> all of Shiro in your Spring files and only touch web.xml only when
>>>>>> setting up Shiro for the first time.
>>>>>>
>>>>>> There are many benefits for Spring users when configuring Shiro
>>>>>> entirely in Spring instead of in web.xml:
>>>>>>
>>>>>> 1) Shiro configuration can live along side where you configure the
>>>>>> rest of your application - no need to flip back between web.xml and
>>>>>> spring files when making configuration changes.
>>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>>>>> benefits, such as PropertyPlaceholderConfigurer for properties based
>>>>>> configuration at startup, spring-managed lifecycles (init-method,
>>>>>> destroy-method), circular dependency checks, and more.
>>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>>>>>> url-pattern-based filter chain definitions can also be defined in
>>>>>> Spring and acquired automatically at startup.
>>>>>>
>>>>>> The current documentation for all of this is located here:
>>>>>>
>>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>>>>
>>>>>> Please feel free to review and offer suggestions/improvements. The
>>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>>>>>> new ShiroFilterFactoryBean) have been tested and the two spring web
>>>>>> sample applications have been updated to use this approach.
>>>>>>
>>>>>> Early adopters are encouraged to use this newer support before 1.0 is
>>>>>> released as there probably won't be any significant changes to this
>>>>>> mechanism before then. (SecurityManager configuration might be
>>>>>> simplified via a Spring FactoryBean as well, but that won't affect web
>>>>>> configuration).
>>>>>>
>>>>>> Please give it a try and let us know what you think!
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Les
>>>>>>
>>>>
>>
>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Les Hazlewood <lh...@apache.org>.
Hi Tauren,
Yep, this is pretty customary in Maven poms as I understand it, but
I'd love to hear if there is a better way. I have to do this
regularly for any dependency that pulls in commons-logging - I have to
manually exclude it since I use SLF4J's version instead.
If there's a better way, I'm all ears!
Cheers,
Les
On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <yo...@gmail.com> wrote:
> Can something be done to make Shiro support either Spring 2.5.6 or Spring
> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found that
> Shiro was including spring 2.5.6 as a dependency. I had to manually exclude
> it in my pom.
> <dependency>
> <groupId>org.apache.shiro</groupId>
> <artifactId>shiro-spring</artifactId>
> <version>${shiro.version}</version>
> <exclusions>
> <exclusion>
> <groupId>org.springframework</groupId>
> <artifactId>spring</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> The good news is that this doesn't seem to have caused any problems for my
> application. I saw another project that manages to support both versions in
> their pom, but can't remember which project it was or how they did it. I'll
> try to find it if it would help.
> Of course I'm open to suggestions if there is a better way to deal with
> this.
> Thanks,
> Tauren
>
> On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
>>
>> ah, the question wasnt how to check, but how to configure.
>> I mean how do u abandon the shiro.ini roles & permissions mechanism for
>> TextConfigurationRealm etc and model it in spring instead.
>> I thought in a previous post you mentioned this should be done.
>>
>> re the useage though I'm really keen for an aop solution, and an xml
>> element something like this:
>> <shiro:requires permissions="user:edit"/>
>> that I could just drop into any spring bean would be great. far better for
>> me than annotations.
>>
>> Cheers
>> Jason.
>>
>>
>> Les Hazlewood wrote:
>>>
>>> Hi Jason,
>>>
>>> What do you mean by 'configure permissions' exactly? Typically
>>> permission checks in standalone applications are done by explicitly
>>> checking (subject.isPermitted(blah)) or using Shiro's
>>> @RequiresPermissions annotation.
>>>
>>> Regards,
>>>
>>> Les
>>>
>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au>
>>> wrote:
>>>>
>>>> thanks!
>>>> now how do I configure permissions etc in spring for a standalone app?
>>>>
>>>>
>>>> Les Hazlewood wrote:
>>>>>
>>>>> The upcoming Shiro 1.0 release will have improved Spring application
>>>>> support, especially for Spring web applications.
>>>>>
>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>>>> configuration - you would usually define an INI-based Shiro Filter in
>>>>> web.xml and configure it via INI mechanisms. But often you would
>>>>> configure the SecurityManager and its dependencies (Realms, etc) in
>>>>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>>>>> all of Shiro in your Spring files and only touch web.xml only when
>>>>> setting up Shiro for the first time.
>>>>>
>>>>> There are many benefits for Spring users when configuring Shiro
>>>>> entirely in Spring instead of in web.xml:
>>>>>
>>>>> 1) Shiro configuration can live along side where you configure the
>>>>> rest of your application - no need to flip back between web.xml and
>>>>> spring files when making configuration changes.
>>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>>>> benefits, such as PropertyPlaceholderConfigurer for properties based
>>>>> configuration at startup, spring-managed lifecycles (init-method,
>>>>> destroy-method), circular dependency checks, and more.
>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>>>>> url-pattern-based filter chain definitions can also be defined in
>>>>> Spring and acquired automatically at startup.
>>>>>
>>>>> The current documentation for all of this is located here:
>>>>>
>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>>>
>>>>> Please feel free to review and offer suggestions/improvements. The
>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>>>>> new ShiroFilterFactoryBean) have been tested and the two spring web
>>>>> sample applications have been updated to use this approach.
>>>>>
>>>>> Early adopters are encouraged to use this newer support before 1.0 is
>>>>> released as there probably won't be any significant changes to this
>>>>> mechanism before then. (SecurityManager configuration might be
>>>>> simplified via a Spring FactoryBean as well, but that won't affect web
>>>>> configuration).
>>>>>
>>>>> Please give it a try and let us know what you think!
>>>>>
>>>>> Best,
>>>>>
>>>>> Les
>>>>>
>>>
>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Tauren Mills <yo...@gmail.com>.
Can something be done to make Shiro support either Spring 2.5.6 or Spring
3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found that
Shiro was including spring 2.5.6 as a dependency. I had to manually exclude
it in my pom.
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-spring</artifactId>
<version>${shiro.version}</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
</exclusions>
</dependency>
The good news is that this doesn't seem to have caused any problems for my
application. I saw another project that manages to support both versions in
their pom, but can't remember which project it was or how they did it. I'll
try to find it if it would help.
Of course I'm open to suggestions if there is a better way to deal with
this.
Thanks,
Tauren
On Fri, Jan 22, 2010 at 5:59 PM, Jason <ja...@hardlight.com.au> wrote:
> ah, the question wasnt how to check, but how to configure.
> I mean how do u abandon the shiro.ini roles & permissions mechanism for
> TextConfigurationRealm etc and model it in spring instead.
> I thought in a previous post you mentioned this should be done.
>
> re the useage though I'm really keen for an aop solution, and an xml
> element something like this:
> <shiro:requires permissions="user:edit"/>
> that I could just drop into any spring bean would be great. far better for
> me than annotations.
>
> Cheers
> Jason.
>
>
>
> Les Hazlewood wrote:
>
>> Hi Jason,
>>
>> What do you mean by 'configure permissions' exactly? Typically
>> permission checks in standalone applications are done by explicitly
>> checking (subject.isPermitted(blah)) or using Shiro's
>> @RequiresPermissions annotation.
>>
>> Regards,
>>
>> Les
>>
>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au>
>> wrote:
>>
>>> thanks!
>>> now how do I configure permissions etc in spring for a standalone app?
>>>
>>>
>>> Les Hazlewood wrote:
>>>
>>>> The upcoming Shiro 1.0 release will have improved Spring application
>>>> support, especially for Spring web applications.
>>>>
>>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>>> configuration - you would usually define an INI-based Shiro Filter in
>>>> web.xml and configure it via INI mechanisms. But often you would
>>>> configure the SecurityManager and its dependencies (Realms, etc) in
>>>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>>>> all of Shiro in your Spring files and only touch web.xml only when
>>>> setting up Shiro for the first time.
>>>>
>>>> There are many benefits for Spring users when configuring Shiro
>>>> entirely in Spring instead of in web.xml:
>>>>
>>>> 1) Shiro configuration can live along side where you configure the
>>>> rest of your application - no need to flip back between web.xml and
>>>> spring files when making configuration changes.
>>>> 2) Shiro configuration can leverage Spring-specific configuration
>>>> benefits, such as PropertyPlaceholderConfigurer for properties based
>>>> configuration at startup, spring-managed lifecycles (init-method,
>>>> destroy-method), circular dependency checks, and more.
>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>>>> url-pattern-based filter chain definitions can also be defined in
>>>> Spring and acquired automatically at startup.
>>>>
>>>> The current documentation for all of this is located here:
>>>>
>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>>
>>>> Please feel free to review and offer suggestions/improvements. The
>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>>>> new ShiroFilterFactoryBean) have been tested and the two spring web
>>>> sample applications have been updated to use this approach.
>>>>
>>>> Early adopters are encouraged to use this newer support before 1.0 is
>>>> released as there probably won't be any significant changes to this
>>>> mechanism before then. (SecurityManager configuration might be
>>>> simplified via a Spring FactoryBean as well, but that won't affect web
>>>> configuration).
>>>>
>>>> Please give it a try and let us know what you think!
>>>>
>>>> Best,
>>>>
>>>> Les
>>>>
>>>>
>>
Re: [ANN] Upcoming enhanced Spring support
Posted by Jason <ja...@hardlight.com.au>.
ah, the question wasnt how to check, but how to configure.
I mean how do u abandon the shiro.ini roles & permissions mechanism for
TextConfigurationRealm etc and model it in spring instead.
I thought in a previous post you mentioned this should be done.
re the useage though I'm really keen for an aop solution, and an xml
element something like this:
<shiro:requires permissions="user:edit"/>
that I could just drop into any spring bean would be great. far better
for me than annotations.
Cheers
Jason.
Les Hazlewood wrote:
> Hi Jason,
>
> What do you mean by 'configure permissions' exactly? Typically
> permission checks in standalone applications are done by explicitly
> checking (subject.isPermitted(blah)) or using Shiro's
> @RequiresPermissions annotation.
>
> Regards,
>
> Les
>
> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au> wrote:
>> thanks!
>> now how do I configure permissions etc in spring for a standalone app?
>>
>>
>> Les Hazlewood wrote:
>>> The upcoming Shiro 1.0 release will have improved Spring application
>>> support, especially for Spring web applications.
>>>
>>> In Shiro-enabled Spring web apps today, there was often a hybrid
>>> configuration - you would usually define an INI-based Shiro Filter in
>>> web.xml and configure it via INI mechanisms. But often you would
>>> configure the SecurityManager and its dependencies (Realms, etc) in
>>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>>> all of Shiro in your Spring files and only touch web.xml only when
>>> setting up Shiro for the first time.
>>>
>>> There are many benefits for Spring users when configuring Shiro
>>> entirely in Spring instead of in web.xml:
>>>
>>> 1) Shiro configuration can live along side where you configure the
>>> rest of your application - no need to flip back between web.xml and
>>> spring files when making configuration changes.
>>> 2) Shiro configuration can leverage Spring-specific configuration
>>> benefits, such as PropertyPlaceholderConfigurer for properties based
>>> configuration at startup, spring-managed lifecycles (init-method,
>>> destroy-method), circular dependency checks, and more.
>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>>> url-pattern-based filter chain definitions can also be defined in
>>> Spring and acquired automatically at startup.
>>>
>>> The current documentation for all of this is located here:
>>>
>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>>
>>> Please feel free to review and offer suggestions/improvements. The
>>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>>> new ShiroFilterFactoryBean) have been tested and the two spring web
>>> sample applications have been updated to use this approach.
>>>
>>> Early adopters are encouraged to use this newer support before 1.0 is
>>> released as there probably won't be any significant changes to this
>>> mechanism before then. (SecurityManager configuration might be
>>> simplified via a Spring FactoryBean as well, but that won't affect web
>>> configuration).
>>>
>>> Please give it a try and let us know what you think!
>>>
>>> Best,
>>>
>>> Les
>>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Les Hazlewood <lh...@apache.org>.
Hi Jason,
What do you mean by 'configure permissions' exactly? Typically
permission checks in standalone applications are done by explicitly
checking (subject.isPermitted(blah)) or using Shiro's
@RequiresPermissions annotation.
Regards,
Les
On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <ja...@hardlight.com.au> wrote:
> thanks!
> now how do I configure permissions etc in spring for a standalone app?
>
>
> Les Hazlewood wrote:
>>
>> The upcoming Shiro 1.0 release will have improved Spring application
>> support, especially for Spring web applications.
>>
>> In Shiro-enabled Spring web apps today, there was often a hybrid
>> configuration - you would usually define an INI-based Shiro Filter in
>> web.xml and configure it via INI mechanisms. But often you would
>> configure the SecurityManager and its dependencies (Realms, etc) in
>> applicationContext.xml. In Shiro 1.0, you will be able to configure
>> all of Shiro in your Spring files and only touch web.xml only when
>> setting up Shiro for the first time.
>>
>> There are many benefits for Spring users when configuring Shiro
>> entirely in Spring instead of in web.xml:
>>
>> 1) Shiro configuration can live along side where you configure the
>> rest of your application - no need to flip back between web.xml and
>> spring files when making configuration changes.
>> 2) Shiro configuration can leverage Spring-specific configuration
>> benefits, such as PropertyPlaceholderConfigurer for properties based
>> configuration at startup, spring-managed lifecycles (init-method,
>> destroy-method), circular dependency checks, and more.
>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
>> url-pattern-based filter chain definitions can also be defined in
>> Spring and acquired automatically at startup.
>>
>> The current documentation for all of this is located here:
>>
>> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>>
>> Please feel free to review and offer suggestions/improvements. The
>> mechanisms documented (using Spring's DelegatingFilterProxy and the
>> new ShiroFilterFactoryBean) have been tested and the two spring web
>> sample applications have been updated to use this approach.
>>
>> Early adopters are encouraged to use this newer support before 1.0 is
>> released as there probably won't be any significant changes to this
>> mechanism before then. (SecurityManager configuration might be
>> simplified via a Spring FactoryBean as well, but that won't affect web
>> configuration).
>>
>> Please give it a try and let us know what you think!
>>
>> Best,
>>
>> Les
>>
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Jason Eacott <ja...@hardlight.com.au>.
thanks!
now how do I configure permissions etc in spring for a standalone app?
Les Hazlewood wrote:
> The upcoming Shiro 1.0 release will have improved Spring application
> support, especially for Spring web applications.
>
> In Shiro-enabled Spring web apps today, there was often a hybrid
> configuration - you would usually define an INI-based Shiro Filter in
> web.xml and configure it via INI mechanisms. But often you would
> configure the SecurityManager and its dependencies (Realms, etc) in
> applicationContext.xml. In Shiro 1.0, you will be able to configure
> all of Shiro in your Spring files and only touch web.xml only when
> setting up Shiro for the first time.
>
> There are many benefits for Spring users when configuring Shiro
> entirely in Spring instead of in web.xml:
>
> 1) Shiro configuration can live along side where you configure the
> rest of your application - no need to flip back between web.xml and
> spring files when making configuration changes.
> 2) Shiro configuration can leverage Spring-specific configuration
> benefits, such as PropertyPlaceholderConfigurer for properties based
> configuration at startup, spring-managed lifecycles (init-method,
> destroy-method), circular dependency checks, and more.
> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
> url-pattern-based filter chain definitions can also be defined in
> Spring and acquired automatically at startup.
>
> The current documentation for all of this is located here:
>
> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>
> Please feel free to review and offer suggestions/improvements. The
> mechanisms documented (using Spring's DelegatingFilterProxy and the
> new ShiroFilterFactoryBean) have been tested and the two spring web
> sample applications have been updated to use this approach.
>
> Early adopters are encouraged to use this newer support before 1.0 is
> released as there probably won't be any significant changes to this
> mechanism before then. (SecurityManager configuration might be
> simplified via a Spring FactoryBean as well, but that won't affect web
> configuration).
>
> Please give it a try and let us know what you think!
>
> Best,
>
> Les
>
Re: [ANN] Upcoming enhanced Spring support
Posted by Jason Eacott <ja...@hardlight.com.au>.
thanks!
now how do I configure permissions etc in spring for a standalone app?
Les Hazlewood wrote:
> The upcoming Shiro 1.0 release will have improved Spring application
> support, especially for Spring web applications.
>
> In Shiro-enabled Spring web apps today, there was often a hybrid
> configuration - you would usually define an INI-based Shiro Filter in
> web.xml and configure it via INI mechanisms. But often you would
> configure the SecurityManager and its dependencies (Realms, etc) in
> applicationContext.xml. In Shiro 1.0, you will be able to configure
> all of Shiro in your Spring files and only touch web.xml only when
> setting up Shiro for the first time.
>
> There are many benefits for Spring users when configuring Shiro
> entirely in Spring instead of in web.xml:
>
> 1) Shiro configuration can live along side where you configure the
> rest of your application - no need to flip back between web.xml and
> spring files when making configuration changes.
> 2) Shiro configuration can leverage Spring-specific configuration
> benefits, such as PropertyPlaceholderConfigurer for properties based
> configuration at startup, spring-managed lifecycles (init-method,
> destroy-method), circular dependency checks, and more.
> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful
> url-pattern-based filter chain definitions can also be defined in
> Spring and acquired automatically at startup.
>
> The current documentation for all of this is located here:
>
> http://cwiki.apache.org/confluence/display/SHIRO/Spring
>
> Please feel free to review and offer suggestions/improvements. The
> mechanisms documented (using Spring's DelegatingFilterProxy and the
> new ShiroFilterFactoryBean) have been tested and the two spring web
> sample applications have been updated to use this approach.
>
> Early adopters are encouraged to use this newer support before 1.0 is
> released as there probably won't be any significant changes to this
> mechanism before then. (SecurityManager configuration might be
> simplified via a Spring FactoryBean as well, but that won't affect web
> configuration).
>
> Please give it a try and let us know what you think!
>
> Best,
>
> Les
>