Re: Integrating tynamo tapestry-security (apache shiro)

[Magnus Kvalheim]

Hi Kalle - thanks for reply,

I've created an issue for #1

http://jira.codehaus.org/browse/TYNAMO-87

--magnus

On Fri, Mar 4, 2011 at 6:23 PM, Kalle Korhonen
wrote:

> On Fri, Mar 4, 2011 at 1:49 AM, Magnus Kvalheim 
> wrote:
> > This post is mostly related to tapestry-security, but I hope it's ok to
> post
> > here in tapestry mailing list (now that Kalle is a committer and all.. :)
> )
> > So I finally decided to implement tapestry-security. Had a few bumps in
> the
> > road, as I will come back to, but all in all I must say it's been a
> > pleasure.
>
> Thanks for the extensive usage report Magnus! I've used
> tapestry-security in so many projects now that I now it works well but
> that said, I do want it to cover *all* security use cases.
>
> > 1. Make tapestry-security localization aware
> > When specifying urls for AccessControlFilters, either in shiro.ini or
> while
> > setting applicationDefaults tapestry-security does not seem to honor
> > localization.
> > So if I'm in accessing though /en paths - then I'm redirected to a /  and
> > loose the localization info.
> > I have not been able to solve this yet.
>
> Please open a (Tynamo) issue for it and I get to it.
>
> > 2. shiro.ini or module configuration - I'm confused
> > The tapestry-security documentation say you can configure shiro in either
> > shiro.ini or in module.
> > I might be wrong here, but it seems that from module you can only
> configure
> > redirect urls, and FilterChainDefinitions
> > through contributeSecurityRequestFilter.
>
> You are right, currently shiro.ini is needed for configuring that. I
> had made a separate jsecurity integration myself and the functionality
> is available in tapestry-security 0.1.0, but that part is yet to
> merged into current tapestry-security codebase (which is the result of
> work from multiple contributors). I think I had even an issue opened
> for it.. yes this is related:
> http://jira.codehaus.org/browse/TYNAMO-76 (there's more, but I spare
> you from the details).
>
> > 3. Problems doing logout from tapestry
> > (I've just found a different post regarding this with subject: "Error
> after
> > logout")
> > I found that when shiro is doing logout it invalidates the session in the
> > end.
>
> You can log out alright, but you just get the ugly stack traces if
> Tapestry doesn't know about it before hand. Howard by the way fixed
> that already in T5.3. What you ended up doing is exactly how I've done
> it in numerous samples we have for tapestry-security. As always, the
> documentation could be improved...
>
> Kalle
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Integrating tynamo tapestry-security (apache shiro)

[Kalle Korhonen]

On Fri, Mar 4, 2011 at 1:49 AM, Magnus Kvalheim  wrote:
> This post is mostly related to tapestry-security, but I hope it's ok to post
> here in tapestry mailing list (now that Kalle is a committer and all.. :) )
> So I finally decided to implement tapestry-security. Had a few bumps in the
> road, as I will come back to, but all in all I must say it's been a
> pleasure.

Thanks for the extensive usage report Magnus! I've used
tapestry-security in so many projects now that I now it works well but
that said, I do want it to cover *all* security use cases.

> 1. Make tapestry-security localization aware
> When specifying urls for AccessControlFilters, either in shiro.ini or while
> setting applicationDefaults tapestry-security does not seem to honor
> localization.
> So if I'm in accessing though /en paths - then I'm redirected to a /  and
> loose the localization info.
> I have not been able to solve this yet.

Please open a (Tynamo) issue for it and I get to it.

> 2. shiro.ini or module configuration - I'm confused
> The tapestry-security documentation say you can configure shiro in either
> shiro.ini or in module.
> I might be wrong here, but it seems that from module you can only configure
> redirect urls, and FilterChainDefinitions
> through contributeSecurityRequestFilter.

You are right, currently shiro.ini is needed for configuring that. I
had made a separate jsecurity integration myself and the functionality
is available in tapestry-security 0.1.0, but that part is yet to
merged into current tapestry-security codebase (which is the result of
work from multiple contributors). I think I had even an issue opened
for it.. yes this is related:
http://jira.codehaus.org/browse/TYNAMO-76 (there's more, but I spare
you from the details).

> 3. Problems doing logout from tapestry
> (I've just found a different post regarding this with subject: "Error after
> logout")
> I found that when shiro is doing logout it invalidates the session in the
> end.

You can log out alright, but you just get the ugly stack traces if
Tapestry doesn't know about it before hand. Howard by the way fixed
that already in T5.3. What you ended up doing is exactly how I've done
it in numerous samples we have for tapestry-security. As always, the
documentation could be improved...

Kalle

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Integrating tynamo tapestry-security (apache shiro)

[Magnus Kvalheim]

Hi,

This post is mostly related to tapestry-security, but I hope it's ok to post
here in tapestry mailing list (now that Kalle is a committer and all.. :) )

So I finally decided to implement tapestry-security. Had a few bumps in the
road, as I will come back to, but all in all I must say it's been a
pleasure.
Using:
Tapestry 5.2.4
Tapestry-Security: 0.3.1

Initially I had a custom authentication dispatcher for restricting access,
and a cookie rememberme (also a dispatcher).

With tapestry-security and shiro I get a feature rich authentication and
authorization framework based on roles and permissions and it's been
pretty strait forward to replace the dispatchers with tapestry-security.
I have however decided to keep the cookie dispatcher as a fallback for the
users so they don't have to reauthenticate with shiro. If such a user visits
- then the user will be looked up, and logged in with shiro (now with a
shiro rememberme manager). I think it's a gentle transition.

I had some challenges along the way.
Perhaps it can be useful for others, and it would be great for some feedback
in case it can be done in a better way (or if I've just missed correct way
of configuration).

1. *Make tapestry-security localization aware*
When specifying urls for AccessControlFilters, either in shiro.ini or while
setting applicationDefaults tapestry-security does not seem to honor
localization.
So if I'm in accessing though /en paths - then I'm redirected to a /  and
loose the localization info.
I have not been able to solve this yet.

2. *shiro.ini or module configuration - I'm confused*
The tapestry-security documentation say you can configure shiro in either
shiro.ini or in module.
I might be wrong here, but it seems that from module you can only configure
redirect urls, and FilterChainDefinitions
through contributeSecurityRequestFilter.
For example I needed to implement my own RememberMeManager for customizing
the cookie ttl (I want to set either a long lived cookie or sessioncookie
depending on condition).
I first tried to do this in shiro.ini:
*[main]*
*# Objects and their properties are defined here,*
*# Such as the securityManager, Realms and anything*
*# else needed to build the SecurityManager*
*myRememberMeManager = com.movellas.web.security.MyCookieRemberMeManager*
*securityManager.rememberMeManager = $myRememberMeManager*

I can see my manager is instantiated, but somehow it's beeing discarded and
the standard CookieRememberMeManager takes precedence.
What I ended up doing is probably not recommended, but it works.
In appmodule:
*/***
* * This is probably not recommended, but we need to somehow supply our own
remembermanager.*
* * If this is specified in shiro.ini, then it will be overridden by
Tynamo's TapestryRealmSecurityManager*
* * @param manager*
* * @return*
* */*
*@Match("WebSecurityManager")*
*public static WebSecurityManager
decorateWebSecurityManager(WebSecurityManager manager) {*
* if(manager instanceof TapestryRealmSecurityManager) {  *
* MyCookieRemberMeManager cmanager = new MyCookieRemberMeManager(); *
* cmanager.setCipherKey(Base64.decode("##=="));*
* ((TapestryRealmSecurityManager)manager).setRememberMeManager(cmanager);*
* }*
* return null;*
*}*
*
*
I get the reference to the security manger, but don't really decorate - just
change the remembermemanger. (I also change the cipherKey.)
Please let me know if someone has a better suggestion.
What can be configured from shiro.ini and what can be configured in module?
(It would seem like some part's of the ini configuration is just thrown
away.)

3.* Problems doing logout from tapestry*
(I've just found a different post regarding this with subject: "Error after
logout")
I found that when shiro is doing logout it invalidates the session in the
end.
As tapestry is using a Request service which 'shadows' the
httpservletrequest and keeps an internal state, it is not informed that the
session is actually invalidated elsewhere.
It therefore tries to access the session and exceptions are thrown. I tried
experimenting with the order of doing things, and got different exceptions.
Currently I use this variant.
Logout.java
*Object onActivate() { *
* /***
* * The order is important as shiro uses the 'real' httpsession.*
* * Upon logout shiro clears session and cache and if session is already
invalidated - an exception occur.*
* * *
* * Tapestry on the other hand uses a session facade and if the 'real'
httpsession is invalidated then the facade don't know about it as it
maintains it's own state.*
* * This causes tapestry to fail internally.*
* * *
* * So the strategy is: Let shiro perform logout, then invalidate tapestry's
session and catch IllegalStateException as result of it.*
* */ *
* //1. Logout shiro*
* securityService.getSubject().logout();*
* //2. Logout legacy*
* 
if(!Validator.isBlankOrNull(cookies.readCookieValue(CookieHelper.LOGIN_COOKIE)))
{*
* cookies.removeCookieValue(CookieHelper.LOGIN_COOKIE);*
* } *
* try {*
* Session ses