| This interceptor populates the
SecurityContextHolder with information obtained from the
PortletSession. It is applied to both ActionRequests and
RenderRequests
The PortletSession will be queried to retrieve the SecurityContext that should
be stored against the SecurityContextHolder for the duration of the portlet request. At the
end of the request, any updates made to the SecurityContextHolder will be persisted back to the
PortletSession by this interceptor.
If a valid SecurityContext cannot be obtained from the PortletSession for
whatever reason, a fresh SecurityContext will be created and used instead. The created object
will be of the instance defined by the
PortletSessionContextIntegrationInterceptor.setContext(Class) method (which defaults to
org.acegisecurity.context.SecurityContextImpl .
A PortletSession may be created by this interceptor if one does not already exist. If at the
end of the portlet request the PortletSession does not exist, one will only be created if
the current contents of the SecurityContextHolder are not the
java.lang.Object.equals to a new instance of
PortletSessionContextIntegrationInterceptor.context . This avoids needless PortletSession creation,
and automates the storage of changes made to the SecurityContextHolder. There is one exception to
this rule, that is if the
PortletSessionContextIntegrationInterceptor.forceEagerSessionCreation property is true, in which case
sessions will always be created irrespective of normal session-minimization logic (the default is
false, as this is resource intensive and not recommended).
If for whatever reason no PortletSession should ever be created, the
PortletSessionContextIntegrationInterceptor.allowSessionCreation property should be set to false. Only do this if you really need
to conserve server memory and ensure all classes using the SecurityContextHolder are designed to
have no persistence of the SecurityContext between web requests. Please note that if
PortletSessionContextIntegrationInterceptor.forceEagerSessionCreation is true, the allowSessionCreation must also be
true (setting it to false will cause a startup-time error).
This interceptor must be executed before any authentication processing mechanisms. These
mechanisms (specifically
org.acegisecurity.ui.portlet.PortletProcessingInterceptor ) expect the
SecurityContextHolder to contain a valid SecurityContext by the time they execute.
An important nuance to this interceptor is that (by default) the SecurityContext is stored
into the APPLICATION_SCOPE of the PortletSession. This doesn't just mean you will be
sharing it with all the other portlets in your webapp (which is generally a good idea). It also means that (if
you have done all the other appropriate magic), you will share this SecurityContext with servlets in
your webapp. This is very useful if you have servlets serving images or processing AJAX calls from your portlets
since they can now use the
HttpSessionContextIntegrationFilter to access the same SecurityContext
object from the session. This allows these calls to be secured as well as the portlet calls.
Much of the logic of this interceptor comes from the
HttpSessionContextIntegrationFilter class which
fills the same purpose on the servlet side. Ben Alex and Patrick Burlson are listed as authors here because they
are the authors of that class and there are blocks of code that essentially identical between the two. (Making this
a good candidate for refactoring someday.)
Unlike HttpSessionContextIntegrationFilter, this interceptor does not check to see if it is
getting applied multiple times. This shouldn't be a problem since the application of interceptors is under the
control of the Spring Portlet MVC framework and tends to be more explicit and more predictable than the application
of filters. However, you should still be careful to only apply this inteceptor to your request once.
author:
John A. Lewis
author:
Ben Alex
author:
Patrick Burleson
since:
2.0
version:
$Id$ | 