You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Neo Anderson <ja...@yahoo.co.uk> on 2009/08/16 18:11:24 UTC
Re: jsecurity integration with Tapestry5
I came across to read this post. Where can I find the example that uses
tapestry 5 and shiro?
Thanks,
Kalle Korhonen wrote:
>
> On Tue, Feb 17, 2009 at 9:37 PM, Les Hazlewood
> <lh...@apache.org>wrote:
>
>> Basically I'm polling your interest of accommodating internal change
>>> requests. If you are already gearing up towards stable 1.0 release you
>>> might
>>> not be interested or not have time for it, but if you welcome
>>> improvement
>>> suggestions on internals of the framework, I'd be happy to work with
>>> you.
>>
>>
>> We would absolutely appreciate your feedback and contributions - I think
>> we're very much open to suggestions prior to 1.0, since it makes sense
>> (at
>> least to me) to get these kinds of additions in place before a 1.0 stable
>> release.
>>
>
> Excellent, it sounds like I'm stepping in at the right time.
>
>
>> The best way is to discuss your ideas and approaches on the dev list
>> which
>> will then probably lead to Jira issues and patches. With enough due
>> diligence and open discussion, there is a very good possibility to become
>> a
>> committer - we're definitely open to others joining the project as
>> committers assuming said due diligence. Just be aware that the ASF
>> requires
>> signing contributor agreements before that can happen (
>> http://www.apache.org/licenses/#clas).
>> So, we definitely look forward to discussion and your ideas. Let loose
>> :)
>>
>
> Thanks for the encouraging reply Les. Yes, I'm subscribed to the dev list,
> but I didn't want to post there out of the blue all-knowingly, proposing
> changes to code that for the intended purpose does work. It's just that
> framework programming *is* difficult because it's impossible to know all
> the
> use cases before people take your code and start using it in a way you
> never
> even thought of... we've all been there - on both sides of the fence I'm
> sure. I don't have a problem being a user for the time being - there's the
> burden of a committer, suddenly you are actually responsible for
> maintaining
> the code and there's only a limited amount of time everybody has. However,
> becoming a committer in this case would open up interesting possibilities
> for me and the good thing is that I'm in a position where I'm allowed to
> allocate some of my time for security related issues. I'm very much aware
> of
> the apache committer process and meritocracy (which makes an interesting
> comparison to Codehaus' dictatorship approach), but never been an Apache
> committer. Anyway, we don't have to worry about it for now, let me just
> annoy you with a flurry of emails to the dev list first ;)
>
> Kalle
>
>
--
View this message in context: http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3453949.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: jsecurity integration with Tapestry5
Posted by Les Hazlewood <lh...@apache.org>.
Hi Neo,
Note that this is changing slightly for Shiro 1.0 to be a little
simpler and more refined. You should use the ShiroFilter source
code[1] as the example to look at when writing your own web framework
support. Look at the doFilterInternal method implementation.
Cheers,
Les
[1] https://svn.apache.org/repos/asf/incubator/shiro/trunk/web/src/main/java/org/apache/shiro/web/servlet/ShiroFilter.java
On Fri, Sep 4, 2009 at 9:28 AM, Neo Anderson
<ja...@yahoo.co.uk> wrote:
>
> Finally I get a bit progress with this issue. Kalle thanks for providing such
> information.
>
> I think other people may have alredy known this but I would like to record
> what I learned so far in case I forget it. I suppose it's because I am new
> to shiro and tapestry so it takes longer time than what I expect to get
> progress.
>
> Basically one can add more behaviour to TapestryFilter.java by implementing
> HttpServletRequestFilter; and configure AppModule to bind
> HttpServletRequestFilter with your own filter impl class.
> (http://www.nabble.com/T5%3A-ServletRequestFilter-and-dependency-injection-ts15347956.html)
>
> Then when it comes to the execution of myfilter.service() method, in which
> to add shiro related code
>
> WebUtils.bindInetAddressToThread(request);
> WebUtils.bind(request);
> WebUtils.bind(response);
> ThreadContext.bind(securityManager);
> ThreadContext.bind(securityManager.getSubject());
> ...
> ...
> ThreadContext.unbindSubject();
> ThreadContext.unbindSecurityManager();
> WebUtils.unbindServletResponse();
> WebUtils.unbindServletRequest();
> WebUtils.unbindInetAddressFromThread();
>
>
>
>
> Kalle Korhonen wrote:
>>
>> Already replied to you privately in a different thread, but as you
>> posted on the list as well, I'll re-post my reply here as well:
>>
>> ---
>> yes this is an integration library that is not part of core Shiro. For
>> years, I've been using and developing Trails framework
>> (http://trailsframework.org/ - though we lost the domain name, but
>> that's another, long story). We have unreleased Tapestry5 integration
>> going, and I've also implemented a few supporting independent modules,
>> tapestry-conversations and tapestry-security. Tapestry-conversations
>> is released, but tapestry-security is still not, which why I haven't
>> made noise about it yet. The documentation for the security module
>> will be something similar I have for Tapestry-conversations (at
>> http://docs.codehaus.org/display/TRAILS/Conversations+in+Trails). If
>> you don't mind living on the bleeding edge, the automatically built
>> snapshots are available via Codehaus snapshot repository at
>> http://ci.repository.codehaus.org/org/trailsframework/tapestry-security/.
>> The module is functional and I'm using it in two projects currently.
>> At this point, you may need to dive into the source code to understand
>> how things work (at
>> http://svn.codehaus.org/trails/trunk/tapestry-security/) but as a
>> teaser :) below is part of the tapestry-security configuration I'm
>> using in one of the projects. Have fun with it!
>>
>> Kalle
>>
>> public static void
>> contributeSecurityConfiguration(OrderedConfiguration<SecurityFilterChain>
>> configuration,
>> SecurityFilterChainFactory
>> securityFilterChainFactory,
>> AnonymousFilter anon, UserFilter user, FormAuthenticationFilter authc,
>> BasicHttpAuthenticationFilter authcBasic,
>> RolesAuthorizationFilter
>> roles, PermissionsAuthorizationFilter perms,
>> RealmSecurityManager securityManager) {
>> String signIn =
>> securityFilterChainFactory.getLogicalUrl(SignIn.class);
>> authc.setLoginUrl(signIn);
>>
>> authc.setSuccessUrl(securityFilterChainFactory.getLogicalUrl(Index.class));
>> SecurityFilterConfiguration filterConfiguration = new
>> SecurityFilterConfiguration();
>> // Add so authc recognizes the authentication try
>> configuration.add(signIn + ".signinform",
>> securityFilterChainFactory.createChain(signIn + "/**",
>> filterConfiguration.add(authc)));
>>
>> filterConfiguration = new SecurityFilterConfiguration();
>> String pageName =
>> securityFilterChainFactory.getLogicalUrl(Participate.class);
>> configuration.add(pageName,
>> securityFilterChainFactory.createChain(pageName + "/**",
>> filterConfiguration.add(authc)));
>>
>> filterConfiguration = new SecurityFilterConfiguration();
>> filterConfiguration.add(roles, "admin");
>> configuration.add("admin",
>> securityFilterChainFactory.createChain("/admin/**",
>> filterConfiguration));
>> ---
>>
>> On Sun, Aug 16, 2009 at 9:11 AM, Neo
>> Anderson<ja...@yahoo.co.uk> wrote:
>>>
>>> I came across to read this post. Where can I find the example that uses
>>> tapestry 5 and shiro?
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Kalle Korhonen wrote:
>>>>
>>>> On Tue, Feb 17, 2009 at 9:37 PM, Les Hazlewood
>>>> <lh...@apache.org>wrote:
>>>>
>>>>> Basically I'm polling your interest of accommodating internal change
>>>>>> requests. If you are already gearing up towards stable 1.0 release you
>>>>>> might
>>>>>> not be interested or not have time for it, but if you welcome
>>>>>> improvement
>>>>>> suggestions on internals of the framework, I'd be happy to work with
>>>>>> you.
>>>>>
>>>>>
>>>>> We would absolutely appreciate your feedback and contributions - I
>>>>> think
>>>>> we're very much open to suggestions prior to 1.0, since it makes sense
>>>>> (at
>>>>> least to me) to get these kinds of additions in place before a 1.0
>>>>> stable
>>>>> release.
>>>>>
>>>>
>>>> Excellent, it sounds like I'm stepping in at the right time.
>>>>
>>>>
>>>>> The best way is to discuss your ideas and approaches on the dev list
>>>>> which
>>>>> will then probably lead to Jira issues and patches. With enough due
>>>>> diligence and open discussion, there is a very good possibility to
>>>>> become
>>>>> a
>>>>> committer - we're definitely open to others joining the project as
>>>>> committers assuming said due diligence. Just be aware that the ASF
>>>>> requires
>>>>> signing contributor agreements before that can happen (
>>>>> http://www.apache.org/licenses/#clas).
>>>>> So, we definitely look forward to discussion and your ideas. Let loose
>>>>> :)
>>>>>
>>>>
>>>> Thanks for the encouraging reply Les. Yes, I'm subscribed to the dev
>>>> list,
>>>> but I didn't want to post there out of the blue all-knowingly, proposing
>>>> changes to code that for the intended purpose does work. It's just that
>>>> framework programming *is* difficult because it's impossible to know all
>>>> the
>>>> use cases before people take your code and start using it in a way you
>>>> never
>>>> even thought of... we've all been there - on both sides of the fence I'm
>>>> sure. I don't have a problem being a user for the time being - there's
>>>> the
>>>> burden of a committer, suddenly you are actually responsible for
>>>> maintaining
>>>> the code and there's only a limited amount of time everybody has.
>>>> However,
>>>> becoming a committer in this case would open up interesting
>>>> possibilities
>>>> for me and the good thing is that I'm in a position where I'm allowed to
>>>> allocate some of my time for security related issues. I'm very much
>>>> aware
>>>> of
>>>> the apache committer process and meritocracy (which makes an interesting
>>>> comparison to Codehaus' dictatorship approach), but never been an Apache
>>>> committer. Anyway, we don't have to worry about it for now, let me just
>>>> annoy you with a flurry of emails to the dev list first ;)
>>>>
>>>> Kalle
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3453949.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3579959.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: jsecurity integration with Tapestry5
Posted by Neo Anderson <ja...@yahoo.co.uk>.
Finally I get a bit progress with this issue. Kalle thanks for providing such
information.
I think other people may have alredy known this but I would like to record
what I learned so far in case I forget it. I suppose it's because I am new
to shiro and tapestry so it takes longer time than what I expect to get
progress.
Basically one can add more behaviour to TapestryFilter.java by implementing
HttpServletRequestFilter; and configure AppModule to bind
HttpServletRequestFilter with your own filter impl class.
(http://www.nabble.com/T5%3A-ServletRequestFilter-and-dependency-injection-ts15347956.html)
Then when it comes to the execution of myfilter.service() method, in which
to add shiro related code
WebUtils.bindInetAddressToThread(request);
WebUtils.bind(request);
WebUtils.bind(response);
ThreadContext.bind(securityManager);
ThreadContext.bind(securityManager.getSubject());
...
...
ThreadContext.unbindSubject();
ThreadContext.unbindSecurityManager();
WebUtils.unbindServletResponse();
WebUtils.unbindServletRequest();
WebUtils.unbindInetAddressFromThread();
Kalle Korhonen wrote:
>
> Already replied to you privately in a different thread, but as you
> posted on the list as well, I'll re-post my reply here as well:
>
> ---
> yes this is an integration library that is not part of core Shiro. For
> years, I've been using and developing Trails framework
> (http://trailsframework.org/ - though we lost the domain name, but
> that's another, long story). We have unreleased Tapestry5 integration
> going, and I've also implemented a few supporting independent modules,
> tapestry-conversations and tapestry-security. Tapestry-conversations
> is released, but tapestry-security is still not, which why I haven't
> made noise about it yet. The documentation for the security module
> will be something similar I have for Tapestry-conversations (at
> http://docs.codehaus.org/display/TRAILS/Conversations+in+Trails). If
> you don't mind living on the bleeding edge, the automatically built
> snapshots are available via Codehaus snapshot repository at
> http://ci.repository.codehaus.org/org/trailsframework/tapestry-security/.
> The module is functional and I'm using it in two projects currently.
> At this point, you may need to dive into the source code to understand
> how things work (at
> http://svn.codehaus.org/trails/trunk/tapestry-security/) but as a
> teaser :) below is part of the tapestry-security configuration I'm
> using in one of the projects. Have fun with it!
>
> Kalle
>
> public static void
> contributeSecurityConfiguration(OrderedConfiguration<SecurityFilterChain>
> configuration,
> SecurityFilterChainFactory
> securityFilterChainFactory,
> AnonymousFilter anon, UserFilter user, FormAuthenticationFilter authc,
> BasicHttpAuthenticationFilter authcBasic,
> RolesAuthorizationFilter
> roles, PermissionsAuthorizationFilter perms,
> RealmSecurityManager securityManager) {
> String signIn =
> securityFilterChainFactory.getLogicalUrl(SignIn.class);
> authc.setLoginUrl(signIn);
>
> authc.setSuccessUrl(securityFilterChainFactory.getLogicalUrl(Index.class));
> SecurityFilterConfiguration filterConfiguration = new
> SecurityFilterConfiguration();
> // Add so authc recognizes the authentication try
> configuration.add(signIn + ".signinform",
> securityFilterChainFactory.createChain(signIn + "/**",
> filterConfiguration.add(authc)));
>
> filterConfiguration = new SecurityFilterConfiguration();
> String pageName =
> securityFilterChainFactory.getLogicalUrl(Participate.class);
> configuration.add(pageName,
> securityFilterChainFactory.createChain(pageName + "/**",
> filterConfiguration.add(authc)));
>
> filterConfiguration = new SecurityFilterConfiguration();
> filterConfiguration.add(roles, "admin");
> configuration.add("admin",
> securityFilterChainFactory.createChain("/admin/**",
> filterConfiguration));
> ---
>
> On Sun, Aug 16, 2009 at 9:11 AM, Neo
> Anderson<ja...@yahoo.co.uk> wrote:
>>
>> I came across to read this post. Where can I find the example that uses
>> tapestry 5 and shiro?
>>
>> Thanks,
>>
>>
>>
>> Kalle Korhonen wrote:
>>>
>>> On Tue, Feb 17, 2009 at 9:37 PM, Les Hazlewood
>>> <lh...@apache.org>wrote:
>>>
>>>> Basically I'm polling your interest of accommodating internal change
>>>>> requests. If you are already gearing up towards stable 1.0 release you
>>>>> might
>>>>> not be interested or not have time for it, but if you welcome
>>>>> improvement
>>>>> suggestions on internals of the framework, I'd be happy to work with
>>>>> you.
>>>>
>>>>
>>>> We would absolutely appreciate your feedback and contributions - I
>>>> think
>>>> we're very much open to suggestions prior to 1.0, since it makes sense
>>>> (at
>>>> least to me) to get these kinds of additions in place before a 1.0
>>>> stable
>>>> release.
>>>>
>>>
>>> Excellent, it sounds like I'm stepping in at the right time.
>>>
>>>
>>>> The best way is to discuss your ideas and approaches on the dev list
>>>> which
>>>> will then probably lead to Jira issues and patches. With enough due
>>>> diligence and open discussion, there is a very good possibility to
>>>> become
>>>> a
>>>> committer - we're definitely open to others joining the project as
>>>> committers assuming said due diligence. Just be aware that the ASF
>>>> requires
>>>> signing contributor agreements before that can happen (
>>>> http://www.apache.org/licenses/#clas).
>>>> So, we definitely look forward to discussion and your ideas. Let loose
>>>> :)
>>>>
>>>
>>> Thanks for the encouraging reply Les. Yes, I'm subscribed to the dev
>>> list,
>>> but I didn't want to post there out of the blue all-knowingly, proposing
>>> changes to code that for the intended purpose does work. It's just that
>>> framework programming *is* difficult because it's impossible to know all
>>> the
>>> use cases before people take your code and start using it in a way you
>>> never
>>> even thought of... we've all been there - on both sides of the fence I'm
>>> sure. I don't have a problem being a user for the time being - there's
>>> the
>>> burden of a committer, suddenly you are actually responsible for
>>> maintaining
>>> the code and there's only a limited amount of time everybody has.
>>> However,
>>> becoming a committer in this case would open up interesting
>>> possibilities
>>> for me and the good thing is that I'm in a position where I'm allowed to
>>> allocate some of my time for security related issues. I'm very much
>>> aware
>>> of
>>> the apache committer process and meritocracy (which makes an interesting
>>> comparison to Codehaus' dictatorship approach), but never been an Apache
>>> committer. Anyway, we don't have to worry about it for now, let me just
>>> annoy you with a flurry of emails to the dev list first ;)
>>>
>>> Kalle
>>>
>>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3453949.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3579959.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: jsecurity integration with Tapestry5
Posted by Kalle Korhonen <ka...@gmail.com>.
Already replied to you privately in a different thread, but as you
posted on the list as well, I'll re-post my reply here as well:
---
yes this is an integration library that is not part of core Shiro. For
years, I've been using and developing Trails framework
(http://trailsframework.org/ - though we lost the domain name, but
that's another, long story). We have unreleased Tapestry5 integration
going, and I've also implemented a few supporting independent modules,
tapestry-conversations and tapestry-security. Tapestry-conversations
is released, but tapestry-security is still not, which why I haven't
made noise about it yet. The documentation for the security module
will be something similar I have for Tapestry-conversations (at
http://docs.codehaus.org/display/TRAILS/Conversations+in+Trails). If
you don't mind living on the bleeding edge, the automatically built
snapshots are available via Codehaus snapshot repository at
http://ci.repository.codehaus.org/org/trailsframework/tapestry-security/.
The module is functional and I'm using it in two projects currently.
At this point, you may need to dive into the source code to understand
how things work (at
http://svn.codehaus.org/trails/trunk/tapestry-security/) but as a
teaser :) below is part of the tapestry-security configuration I'm
using in one of the projects. Have fun with it!
Kalle
public static void
contributeSecurityConfiguration(OrderedConfiguration<SecurityFilterChain>
configuration,
SecurityFilterChainFactory securityFilterChainFactory,
AnonymousFilter anon, UserFilter user, FormAuthenticationFilter authc,
BasicHttpAuthenticationFilter authcBasic,
RolesAuthorizationFilter
roles, PermissionsAuthorizationFilter perms,
RealmSecurityManager securityManager) {
String signIn =
securityFilterChainFactory.getLogicalUrl(SignIn.class);
authc.setLoginUrl(signIn);
authc.setSuccessUrl(securityFilterChainFactory.getLogicalUrl(Index.class));
SecurityFilterConfiguration filterConfiguration = new
SecurityFilterConfiguration();
// Add so authc recognizes the authentication try
configuration.add(signIn + ".signinform",
securityFilterChainFactory.createChain(signIn + "/**",
filterConfiguration.add(authc)));
filterConfiguration = new SecurityFilterConfiguration();
String pageName =
securityFilterChainFactory.getLogicalUrl(Participate.class);
configuration.add(pageName,
securityFilterChainFactory.createChain(pageName + "/**",
filterConfiguration.add(authc)));
filterConfiguration = new SecurityFilterConfiguration();
filterConfiguration.add(roles, "admin");
configuration.add("admin",
securityFilterChainFactory.createChain("/admin/**",
filterConfiguration));
---
On Sun, Aug 16, 2009 at 9:11 AM, Neo
Anderson<ja...@yahoo.co.uk> wrote:
>
> I came across to read this post. Where can I find the example that uses
> tapestry 5 and shiro?
>
> Thanks,
>
>
>
> Kalle Korhonen wrote:
>>
>> On Tue, Feb 17, 2009 at 9:37 PM, Les Hazlewood
>> <lh...@apache.org>wrote:
>>
>>> Basically I'm polling your interest of accommodating internal change
>>>> requests. If you are already gearing up towards stable 1.0 release you
>>>> might
>>>> not be interested or not have time for it, but if you welcome
>>>> improvement
>>>> suggestions on internals of the framework, I'd be happy to work with
>>>> you.
>>>
>>>
>>> We would absolutely appreciate your feedback and contributions - I think
>>> we're very much open to suggestions prior to 1.0, since it makes sense
>>> (at
>>> least to me) to get these kinds of additions in place before a 1.0 stable
>>> release.
>>>
>>
>> Excellent, it sounds like I'm stepping in at the right time.
>>
>>
>>> The best way is to discuss your ideas and approaches on the dev list
>>> which
>>> will then probably lead to Jira issues and patches. With enough due
>>> diligence and open discussion, there is a very good possibility to become
>>> a
>>> committer - we're definitely open to others joining the project as
>>> committers assuming said due diligence. Just be aware that the ASF
>>> requires
>>> signing contributor agreements before that can happen (
>>> http://www.apache.org/licenses/#clas).
>>> So, we definitely look forward to discussion and your ideas. Let loose
>>> :)
>>>
>>
>> Thanks for the encouraging reply Les. Yes, I'm subscribed to the dev list,
>> but I didn't want to post there out of the blue all-knowingly, proposing
>> changes to code that for the intended purpose does work. It's just that
>> framework programming *is* difficult because it's impossible to know all
>> the
>> use cases before people take your code and start using it in a way you
>> never
>> even thought of... we've all been there - on both sides of the fence I'm
>> sure. I don't have a problem being a user for the time being - there's the
>> burden of a committer, suddenly you are actually responsible for
>> maintaining
>> the code and there's only a limited amount of time everybody has. However,
>> becoming a committer in this case would open up interesting possibilities
>> for me and the good thing is that I'm in a position where I'm allowed to
>> allocate some of my time for security related issues. I'm very much aware
>> of
>> the apache committer process and meritocracy (which makes an interesting
>> comparison to Codehaus' dictatorship approach), but never been an Apache
>> committer. Anyway, we don't have to worry about it for now, let me just
>> annoy you with a flurry of emails to the dev list first ;)
>>
>> Kalle
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/jsecurity-integration-with-Tapestry5-tp2342638p3453949.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>