Re: what are the drawback of setting DefaultSubjectContext.AUTHENTICATED_SESSION_KEY in session explicitly?

[ankur <an...@gmail.com>]

Is there anyone who can reply here??
thanks



--
View this message in context: http://shiro-user.582556.n2.nabble.com/what-are-the-drawback-of-setting-DefaultSubjectContext-AUTHENTICATED-SESSION-KEY-in-session-explicit-tp7577720p7577781.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: what are the drawback of setting DefaultSubjectContext.AUTHENTICATED_SESSION_KEY in session explicitly?

[Sean Blaes <se...@hifiit.com>]

This isn't a direct response to your question, but if you use the approach I outlined, I don't believe you need to muck with the session attributes. I'd recommend reading the Shiro source code if you want to know more or step through it in the debugger. It's really pretty simple to dig into.

Here's some of the  code I wrote which may help you…

First, I created a custom SessionManager which just overrides the getSessionId to pull the session ID from a custom HTTP header rather than as a cookie (which is how it's passed in my case, in your case it may be passed differently):

public class AuthTokenSessionManager extends DefaultWebSessionManager { protected Serializable getSessionId(ServletRequest request, ServletResponse response) { HttpServletRequest httpRequest = (HttpServletRequest) request; String id = httpRequest.getHeader("authToken"); // We'll say this is came from a cookie, even if it didn't, because the only supported options are // cookie and URL, and if URL is specified, Shiro will try to encode it into redirect URL's (though we really // con't use redirects much, so that may be irrelevant anyway) request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_SOURCE, ShiroHttpServletRequest.COOKIE_SESSION_ID_SOURCE); request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID, id); request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_IS_VALID, Boolean.TRUE); return id; } }

We also created a custom RememberMeManager that rebuilds the session from cache, though I don't actually think we're using this anymore.

public class AuthTokenRememberMeManager implements RememberMeManager { private static final Logger LOG = LogManager.getLogger(AuthTokenRememberMeManager.class); private Cache authTokenCache; private Cache authCache; public void setAuthTokenCache(Cache authTokenCache) { this.authTokenCache = authTokenCache; } public void setAuthCache(Cache authCache) { this.authCache = authCache; } @Override public PrincipalCollection getRememberedPrincipals(SubjectContext subjectContext) { if (subjectContext.getSessionId() != null){ String object = (String)subjectContext.getSessionId(); if (object != null){ Element element = authTokenCache.get(object); if (element != null){ PrincipalCollection principals = (PrincipalCollection)element.getObjectValue(); return principals; } else { LOG.warn("the context was not found in the cache"); } } } return null; } @Override public void forgetIdentity(SubjectContext subjectContext) { } @Override public void onSuccessfulLogin(Subject subject, AuthenticationToken token, AuthenticationInfo info) { authTokenCache.put(new Element(subject.getSession().getId(), subject.getPrincipals())); } @Override public void onFailedLogin(Subject subject, AuthenticationToken token, AuthenticationException ae) { } @Override public void onLogout(Subject subject) { } }


I then created a custom filter to validate that the user is authenticated and sets the HTTP status if the user is not authenticated:

public class RestPassThruAuthTokenFilter extends PassThruAuthenticationFilter { /** * Convenience method that acquires the Subject associated with the request. * <p/> * The default implementation simply returns * {@link org.apache.shiro.SecurityUtils#getSubject() SecurityUtils.getSubject()}. * * @param request the incoming <code>ServletRequest</code> * @param response the outgoing <code>ServletResponse</code> * @return the Subject associated with the request. */ protected Subject getSubject(ServletRequest request, ServletResponse response) { Subject subject = SecurityUtils.getSubject(); return subject; } protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws Exception { if (isLoginRequest(request, response)) { return true; } else { WebUtils.toHttp(response).setStatus(HttpStatus.FORBIDDEN.value()); WebUtils.toHttp(response).getWriter().write("{ \"error\": \"User is not authenticated or the session has expired\" }"); return false; } } }

I am using the Shiro filter in my web.xml, as follows:

<!-- Shiro Filter is defined in the spring application context. This filter must be defined first!!! --> <filter> <filter-name>shiroFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> <init-param> <param-name>targetFilterLifecycle</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>shiroFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

And in my case I'm using Spring to map all the Shiro logic in, as follows:

<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager"> <property name="cacheManager" ref="shiroCacheManager"/> <property name="sessionManager" ref="authTokenSessionManager"/> <property name="rememberMeManager" ref="authTokenRememberMeManager"/> <property name="realms"> <list> <ref bean="userRealm" /> <ref bean="ldapRealm" /> </list> </property> </bean> <bean id="userRealm" class="....core.accesscontrol.UserPassRealm">
... </bean> <bean id="ldapRealm" class="....accesscontrol.LdapRealm">  


...  
</bean> <bean id="authTokenRememberMeManager" class="....accesscontrol.AuthTokenRememberMeManager"> <property name="authCache" value="#{cacheManager.getCache('authorization')}"/> <property name="authTokenCache" value="#{cacheManager.getCache('authToken')}"/> </bean> <bean id="authTokenSessionManager" class="....accesscontrol.AuthTokenSessionManager"> </bean> <bean id="shiroCacheManager" class="org.apache.shiro.cache.ehcache.EhCacheManager"> <property name="cacheManager" ref="cacheManager"/> </bean> <bean id="lifecycleBeanPostProcessor" class="org.apache.shiro.spring.LifecycleBeanPostProcessor"/> <bean id="RestPassThruAuthTokenFilter" class="....accesscontrol.RestPassThruAuthTokenFilter"> </bean> <bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean"> <property name="securityManager" ref="securityManager"/> <property name="loginUrl" value="/authenticate"/> <property name="filterChainDefinitions"> <value> /application.wadl = anon /ui/application.wadl = anon /account/create = anon /** = RestPassThruAuthTokenFilter </value> </property> </bean>





--  
Sean Blaes
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Wednesday, September 5, 2012 at 12:29 AM, ankur wrote:

> Is there anyone who can reply here??
> thanks
>  
>  
>  
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/what-are-the-drawback-of-setting-DefaultSubjectContext-AUTHENTICATED-SESSION-KEY-in-session-explicit-tp7577720p7577781.html
> Sent from the Shiro User mailing list archive at Nabble.com (http://Nabble.com).
>  
>