I am trying to implement some captcha function, "/UP2/servlet/captch
" is pointing to a servlet, which will generate a random captcha and store it in HttpSession
, and I want to retrieve this later in WebSphere Portal custom portlet.
Here is my captcha image:
<img src="/UP2/servlet/captch" id="captch"/>
Here is servlet to generate captcha String and store in HttpSession
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException{
//...
request.getSession().setAttribute("key", capstr);
//...
}
When I submit the portlet, I want to retrieve the "key" from session, I use below code to retrieve:(The request
here is PortletRequest
(ActionRequest
))
Object jCaptchainput = PortletUtils.getHttpServletRequest(request).getSession().getAttribute("key");
but I always get null
This also not working:
Object jCaptchainput = request.getPortletSession().getAttribute("key", PortletSession.APPLICATION_SCOPE);
Can anyone help me out? Really want to know how to communicate between Servlet
and Portlet
in WebSphere Portal. Thanks in advance.
is this for an authenticated users or unathenticated users? if unathenticated do you have anonymous sessions enabled? I believe you may be running into the below, you can also set it globally via Navigator service with public.session set to true http://www.ibm.com/support/knowledgecenter/SSYJ99_8.0.0/admin/srvcfgref_navigator.html
In this case, a temporary session is created and your session information will be lost in the next request. If you need to enable session tracking across requests for non-authenticated users, you can do so by setting the public.session parameter in the portal Navigator service configuration or by setting the com.ibm.portal.public.session container run time option in a JSR 286 portlet deployment descriptor. Note that this may result in significantly increased memory consumption. For details about the com.ibm.portal.public.session option and a code sample refer to the topic about Deployment descriptors, section about Container run time options. Instead of using these options, portlets that need to maintain interaction state even for non-authenticated users should use render parameters to keep this information instead of the portlet session, as recommended by the Java Portlet Specification.