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/09/04 15:28:22 UTC
Re: jsecurity integration with Tapestry5
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 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.
>