Topic
  • 12 replies
  • Latest Post - ‏2013-12-25T05:37:09Z by DeanHere
DeanHere
DeanHere
9 Posts

Pinned topic how to set auto logout for custom tool when session timeout

‏2013-06-26T02:43:19Z |

So far I know:

session interval, max_inactive_interval in common.properties file.

I searched infor center, got that could reference DemoMainApplication.jsp for setting auto logout for custom tool, but I don't have the source code of this file.

We have a custom tool, jsp, getting data from session, when session time out, user click a button on this page, the application doesn't logout but return an error page, we need it to be navigated to the login page to login again. How to do that?

Thanks.

  • DeanHere
    DeanHere
    9 Posts
    ACCEPTED ANSWER

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-12-25T05:37:09Z  
    • KaranBal
    • ‏2013-11-13T04:36:59Z

    Just to recap our discussion for future reference, for the timeout setting in common.properties to apply, modify the flow-config.xml as shown below:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    Here the com.ibm.ccd.ui.util.DefaultNavigator part controls the flow and if you have that specified then the custom tool will time out just as the rest of the screens do. As mentioned in an earlier post, please change it and test. If it still doesn't time you out, then this is a potential defect but I am confident that it will.
    If you plan to use a custom command, then the normal time out will not apply and I am not sure how you would specify the timeout, maybe you will have to manually time yourself out. I am not familiar with the source code enough to know exactly what changes need to be made because of session management complications. One thing you can try is execute logout.wpcs script during the time inactivity to log the user out but that is very hard to implement and I do not recommend it. I would instead recommend that you open a PMR to confirm whether they it is possible to time out the user without the DefaultNavigator and if it is, then how. Inquiries of this sort are supported.

    Finally if you want a quick workaround without using the DefaultNavigator, then you can specify a timeout at the Websphere level. PIM runs as a business level application in the WAS container and therefore if Websphere times the user out, he would be logged out of PIM by default. Following tech note contains details on how to set the timeout in Websphere:

    http://www-01.ibm.com/support/docview.wss?uid=swg21163875

    got something from IBM Support/developer, 

    in JSP file, add below script:

    <%@ page import="com.ibm.ccd.common.util.StringUtils" %>
    <%@ page import="com.ibm.ccd.common.util.Configuration" %>
    <%@ page import="com.ibm.ccd.common.locale.ResourceList" %>
    <%@ page import="com.ibm.ccd.common.context.AustinContext" %>
    <script language="JavaScript">
      <%
      AustinContext ctx = AustinContext.getCurrentContext();
      // Get session timeout interval from common.properties
      int nServerTimeOutSeconds = StringUtils.checkInt(Configuration.getValue("max_inactive_interval"), 1800);out.println("nServerTimeOutSeconds:"+nServerTimeOutSeconds);
      int nWarningSeconds = nServerTimeOutSeconds/6;out.println("nWarningSeconds:"+nWarningSeconds);
      %>
      // Set global time of session activity
      parent.top.lastPostTime = (new Date()).valueOf();
      function resetSession() {
    // Compute time since last session activity
    var timeSinceLastPost = new Date().valueOf() - parent.top.lastPostTime;
    if (timeSinceLastPost >= <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>) {
     // Popup session warning message if time since last session activity greater than value in common.properties
     if (window.confirm("<%=ctx.getMessage(ResourceList.COMMON_INFO_SESSION_TIME_OUT, new Object[]{(nWarningSeconds/60)+""})%>")) {
    var f = document.reset_session_form;
    // Ping the server to keep session alive
    f.submit();
    // Set timer to recall this function
    window.setTimeout("resetSession()", <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>);
     }
    } else {
     // Set timer to recall this function
     window.setTimeout("resetSession()", <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>-timeSinceLastPost);
    }
      }
      // Start up session count down
      resetSession();
      // Reset the global time of session activity on user action (i.e. click "Search Data" button)
      function resetGlobalTimeOfSessionActivity() {
        parent.top.lastPostTime = (new Date()).valueOf();
      }
    </script>
    < iframe src='/blank.html' application=yes height=0 width=0 name=hidden_frame_for_reset_session_form></iframe>
    < form name=reset_session_form method=get target=hidden_frame_for_reset_session_form action='/blank.jsp'></form>

    still having a question that, if the session already time out, then click a button like Search Data button, still have problem.

    I cannot dig this more since I have been out.

  • KaranBal
    KaranBal
    108 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-26T23:23:35Z  

    The custom tool needs context(via getCurrentContext()) to work properly. If it loses context via timeout, then it will give an error which is what you are seeing. Now to send the user to the login screen, edit the flow-config.xml file to include the DefaultNavigator as per the following information center page: http://pic.dhe.ibm.com/infocenter/mdm/v10r0m0/topic/com.ibm.pim.dev.doc/code/custom/pim_tsk_simplecustomtool.html.

  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-27T01:45:16Z  
    • KaranBal
    • ‏2013-06-26T23:23:35Z

    The custom tool needs context(via getCurrentContext()) to work properly. If it loses context via timeout, then it will give an error which is what you are seeing. Now to send the user to the login screen, edit the flow-config.xml file to include the DefaultNavigator as per the following information center page: http://pic.dhe.ibm.com/infocenter/mdm/v10r0m0/topic/com.ibm.pim.dev.doc/code/custom/pim_tsk_simplecustomtool.html.

    Good to see you here Karan, and thanks for your reply.

    The jsp is importing "com.ibm.pim.context.Context,com.ibm.pim.context.PIMContextFactory", no "getCurrentContext()" in jsp but in the command java class.

    We have custom command in flow-config.xml already, like below:

    <flow path="xxxWorkflowDashboard"
    command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand"
    method="getWorkflowItems">
    <flow-dispatch name="xxxWorkflowDashboard"
    location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />
    </flow>
  • KaranBal
    KaranBal
    108 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-27T02:22:40Z  
    • DeanHere
    • ‏2013-06-27T01:45:16Z

    Good to see you here Karan, and thanks for your reply.

    The jsp is importing "com.ibm.pim.context.Context,com.ibm.pim.context.PIMContextFactory", no "getCurrentContext()" in jsp but in the command java class.

    We have custom command in flow-config.xml already, like below:

    <flow path="xxxWorkflowDashboard"
    command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand"
    method="getWorkflowItems">
    <flow-dispatch name="xxxWorkflowDashboard"
    location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />
    </flow>

    Hi Dean,

    Its been a while since we worked together. For this, just back up the flow-config.xml file and edit this xxxWorkflowDashboard section like:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    .... Same as before

    Theoretically this should mean that if there is a timeout, the custom tool will behave just like the rest of the product is i.e. goes to the log in page. Originally, it was trying to execute your custom code when there was a time out leading to the error. You can also create a PMR for this.

    - Karan

  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-27T03:29:05Z  
    • KaranBal
    • ‏2013-06-27T02:22:40Z

    Hi Dean,

    Its been a while since we worked together. For this, just back up the flow-config.xml file and edit this xxxWorkflowDashboard section like:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    .... Same as before

    Theoretically this should mean that if there is a timeout, the custom tool will behave just like the rest of the product is i.e. goes to the log in page. Originally, it was trying to execute your custom code when there was a time out leading to the error. You can also create a PMR for this.

    - Karan

    Actually I was trying to make the command java class to extends com.ibm.ccd.ui.util.DefaultNavigator, but it was not working, just same as it was not there.

    I am testing to modify flow-config.xml, i still need to modify some code for testing it. But, even it would work, it is not what I want, I need the command. I will try to confirm it.

    I currently have a PMR on this but still not get reply from Support yet. Just want to get some ideas from this forum. Thanks for your help!

  • KaranBal
    KaranBal
    108 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-27T16:31:38Z  
    • DeanHere
    • ‏2013-06-27T03:29:05Z

    Actually I was trying to make the command java class to extends com.ibm.ccd.ui.util.DefaultNavigator, but it was not working, just same as it was not there.

    I am testing to modify flow-config.xml, i still need to modify some code for testing it. But, even it would work, it is not what I want, I need the command. I will try to confirm it.

    I currently have a PMR on this but still not get reply from Support yet. Just want to get some ideas from this forum. Thanks for your help!

    I have not worked extensively on custom tools and I am not sure whether I completely understand what you are trying to do. But the way it works is that while defining the custom tool you mention a link, e.g. <a href="/xyz.wpc">. Then the application looks up the $TOP/etc/default/flow-config.xml file and searches for the section corresponding to xyz.wpc and executes it.

    There are 2 sections in these files corresponding to the flow path and flow-dispatch name. The flow path can be something generic  like the DefaultNavigator because it just makes the behavior consistent in events like time out and what to do when there is an error. It does not effect the execution of the custom code and you can set it to your custom code as well as you have done. But if you do that, then I do not how it will act for error reporting or in cases like timeout. You will have to test it to be sure.


    The flow-dispatch meanwhile controls how the code is executed. Usually it contains sections like:
    <flow-dispatch name="success" location="/success/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="failure" location="/failure/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    This means that if the custom tool returns success, then execute $WAS_CCD_WAR_Location/success/CustomCode.jsp, it if returns failure then execute $WAS_CCD_WAR_Location/failure/CustomCode.jsp, and it is xxxWorkflowDashboard, then return $WAS_CCD_WAR_Location/custom_tools/xxxWorkflowDashboard.jsp. This will depend on exactly what your script is returning. The $WAS_CCD_WAR_Location is equivalent to $Appserver_HOME/profiles/AppSvr01/installedApps/Name_of_the_Cell/Your_ccd_file.ear/ccd.war/utils.

     

    As mentioned earlier, if you use the following, even then it should work:

    <flow path="xxxWorkflowDashboard" command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand" method="getWorkflowItems">

    But I do not know what the timeout behavior will be if you set it this way.

     

    My suggestion would be to us the following and I believe it will do what you are expecting:
    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="success" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-06-28T01:15:02Z  
    • KaranBal
    • ‏2013-06-27T16:31:38Z

    I have not worked extensively on custom tools and I am not sure whether I completely understand what you are trying to do. But the way it works is that while defining the custom tool you mention a link, e.g. <a href="/xyz.wpc">. Then the application looks up the $TOP/etc/default/flow-config.xml file and searches for the section corresponding to xyz.wpc and executes it.

    There are 2 sections in these files corresponding to the flow path and flow-dispatch name. The flow path can be something generic  like the DefaultNavigator because it just makes the behavior consistent in events like time out and what to do when there is an error. It does not effect the execution of the custom code and you can set it to your custom code as well as you have done. But if you do that, then I do not how it will act for error reporting or in cases like timeout. You will have to test it to be sure.


    The flow-dispatch meanwhile controls how the code is executed. Usually it contains sections like:
    <flow-dispatch name="success" location="/success/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="failure" location="/failure/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    This means that if the custom tool returns success, then execute $WAS_CCD_WAR_Location/success/CustomCode.jsp, it if returns failure then execute $WAS_CCD_WAR_Location/failure/CustomCode.jsp, and it is xxxWorkflowDashboard, then return $WAS_CCD_WAR_Location/custom_tools/xxxWorkflowDashboard.jsp. This will depend on exactly what your script is returning. The $WAS_CCD_WAR_Location is equivalent to $Appserver_HOME/profiles/AppSvr01/installedApps/Name_of_the_Cell/Your_ccd_file.ear/ccd.war/utils.

     

    As mentioned earlier, if you use the following, even then it should work:

    <flow path="xxxWorkflowDashboard" command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand" method="getWorkflowItems">

    But I do not know what the timeout behavior will be if you set it this way.

     

    My suggestion would be to us the following and I believe it will do what you are expecting:
    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="success" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    Thanks for the details !

    I will dig more on this by following your explanation.

  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-11-08T14:02:34Z  
    • KaranBal
    • ‏2013-06-27T16:31:38Z

    I have not worked extensively on custom tools and I am not sure whether I completely understand what you are trying to do. But the way it works is that while defining the custom tool you mention a link, e.g. <a href="/xyz.wpc">. Then the application looks up the $TOP/etc/default/flow-config.xml file and searches for the section corresponding to xyz.wpc and executes it.

    There are 2 sections in these files corresponding to the flow path and flow-dispatch name. The flow path can be something generic  like the DefaultNavigator because it just makes the behavior consistent in events like time out and what to do when there is an error. It does not effect the execution of the custom code and you can set it to your custom code as well as you have done. But if you do that, then I do not how it will act for error reporting or in cases like timeout. You will have to test it to be sure.


    The flow-dispatch meanwhile controls how the code is executed. Usually it contains sections like:
    <flow-dispatch name="success" location="/success/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="failure" location="/failure/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    This means that if the custom tool returns success, then execute $WAS_CCD_WAR_Location/success/CustomCode.jsp, it if returns failure then execute $WAS_CCD_WAR_Location/failure/CustomCode.jsp, and it is xxxWorkflowDashboard, then return $WAS_CCD_WAR_Location/custom_tools/xxxWorkflowDashboard.jsp. This will depend on exactly what your script is returning. The $WAS_CCD_WAR_Location is equivalent to $Appserver_HOME/profiles/AppSvr01/installedApps/Name_of_the_Cell/Your_ccd_file.ear/ccd.war/utils.

     

    As mentioned earlier, if you use the following, even then it should work:

    <flow path="xxxWorkflowDashboard" command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand" method="getWorkflowItems">

    But I do not know what the timeout behavior will be if you set it this way.

     

    My suggestion would be to us the following and I believe it will do what you are expecting:
    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="success" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    The PMR was closed last week since Support think its a custom code problem, I have to dig it more.

    A problem, if I create a Custom Tool Script in Script Console as below to point to the section in flow-config.xml, a new jsp, new custom command, then run the tool, there was no session out warning popup, but if i paste the code of the jsp to the Custom Tool Script instead the code below, there was a session out warning popup.  I can see the different source code of tool page without or with some dojo script.

    <script language="Javascript">
      window.location = "newhomepageviacommand.wpc";
    </script>
     
  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-11-12T08:43:14Z  
    • KaranBal
    • ‏2013-06-27T16:31:38Z

    I have not worked extensively on custom tools and I am not sure whether I completely understand what you are trying to do. But the way it works is that while defining the custom tool you mention a link, e.g. <a href="/xyz.wpc">. Then the application looks up the $TOP/etc/default/flow-config.xml file and searches for the section corresponding to xyz.wpc and executes it.

    There are 2 sections in these files corresponding to the flow path and flow-dispatch name. The flow path can be something generic  like the DefaultNavigator because it just makes the behavior consistent in events like time out and what to do when there is an error. It does not effect the execution of the custom code and you can set it to your custom code as well as you have done. But if you do that, then I do not how it will act for error reporting or in cases like timeout. You will have to test it to be sure.


    The flow-dispatch meanwhile controls how the code is executed. Usually it contains sections like:
    <flow-dispatch name="success" location="/success/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="failure" location="/failure/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    This means that if the custom tool returns success, then execute $WAS_CCD_WAR_Location/success/CustomCode.jsp, it if returns failure then execute $WAS_CCD_WAR_Location/failure/CustomCode.jsp, and it is xxxWorkflowDashboard, then return $WAS_CCD_WAR_Location/custom_tools/xxxWorkflowDashboard.jsp. This will depend on exactly what your script is returning. The $WAS_CCD_WAR_Location is equivalent to $Appserver_HOME/profiles/AppSvr01/installedApps/Name_of_the_Cell/Your_ccd_file.ear/ccd.war/utils.

     

    As mentioned earlier, if you use the following, even then it should work:

    <flow path="xxxWorkflowDashboard" command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand" method="getWorkflowItems">

    But I do not know what the timeout behavior will be if you set it this way.

     

    My suggestion would be to us the following and I believe it will do what you are expecting:
    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="success" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    here is the code of DefaultNavigator.class, i also tried to let my custom commad to extend AbstractCommand, but nothing changed.

    package com.ibm.ccd.ui.util;
     
    public class DefaultNavigator extends AbstractCommand
    {
      public String execute()
      {
        return "success";
      }
    }
  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-11-12T13:41:17Z  
    • KaranBal
    • ‏2013-06-27T16:31:38Z

    I have not worked extensively on custom tools and I am not sure whether I completely understand what you are trying to do. But the way it works is that while defining the custom tool you mention a link, e.g. <a href="/xyz.wpc">. Then the application looks up the $TOP/etc/default/flow-config.xml file and searches for the section corresponding to xyz.wpc and executes it.

    There are 2 sections in these files corresponding to the flow path and flow-dispatch name. The flow path can be something generic  like the DefaultNavigator because it just makes the behavior consistent in events like time out and what to do when there is an error. It does not effect the execution of the custom code and you can set it to your custom code as well as you have done. But if you do that, then I do not how it will act for error reporting or in cases like timeout. You will have to test it to be sure.


    The flow-dispatch meanwhile controls how the code is executed. Usually it contains sections like:
    <flow-dispatch name="success" location="/success/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="failure" location="/failure/CustomCode.jsp" dispatchType="forward" />
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    This means that if the custom tool returns success, then execute $WAS_CCD_WAR_Location/success/CustomCode.jsp, it if returns failure then execute $WAS_CCD_WAR_Location/failure/CustomCode.jsp, and it is xxxWorkflowDashboard, then return $WAS_CCD_WAR_Location/custom_tools/xxxWorkflowDashboard.jsp. This will depend on exactly what your script is returning. The $WAS_CCD_WAR_Location is equivalent to $Appserver_HOME/profiles/AppSvr01/installedApps/Name_of_the_Cell/Your_ccd_file.ear/ccd.war/utils.

     

    As mentioned earlier, if you use the following, even then it should work:

    <flow path="xxxWorkflowDashboard" command="com.xxxxxxxxxxxxx.customtools.workflowdashboard.controller.WorkflowDashboardCommand" method="getWorkflowItems">

    But I do not know what the timeout behavior will be if you set it this way.

     

    My suggestion would be to us the following and I believe it will do what you are expecting:
    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="success" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    I checked some java code of PIM commands, looks like they all extending AbstractCommand. I used the getContext(); in AbstractCommand to get context instant but still error out when session is out.

    In additional, there is a PIM class RequestProcessor, 'process' method is having a session null check before processing the custom command, but not sure why it is not returning for my custom command. check the exception log below

          if (null == paramHttpServletRequest.getSession(false))
          {
            paramHttpServletResponse.sendRedirect(this.loginPage);
            return;
          }

     

    com.ibm.pim.common.exceptions.PIMInternalException: CWPAP0137E:No current context is available
            at com.ibm.ccd.api.context.DefaultContextImpl.<init>(Unknown Source)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
            at com.ibm.pim.context.PIMContextFactory.getCurrentContextInternal(Unknown Source)
            at com.ibm.pim.context.PIMContextFactory$1.initialValue(Unknown Source)
            at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:152)
            at java.lang.ThreadLocal.get(ThreadLocal.java:142)
            at com.ibm.pim.context.PIMContextFactory.getCurrentContext(Unknown Source)
            at com.ibm.ccd.ui.util.AbstractCommand.getContext(Unknown Source)
            at com.staples.pim.pimcore.extensionpoint.customtools.workflowdashboard.controller.WorkflowDashboardCommand.getWorkflowItems(WorkflowDashboardCommand.java:94)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
            at java.lang.reflect.Method.invoke(Method.java:611)
            at com.ibm.pim.web.framework.dispatcher.RequestProcessor.process(Unknown Source)
            at com.ibm.pim.web.framework.dispatcher.WPCControllerServlet.doProcess(Unknown Source)
            at com.ibm.pim.web.framework.dispatcher.WPCControllerServlet.doGet(Unknown Source)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
            at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1657)
            at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1597)
            at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:131)
            at com.ibm.ccd.ui.filters.FuzaoRequestFilter.doFilter(Unknown Source)
            at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
            at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
            at com.ibm.ccd.ui.filters.ResponseHeaderFilter.doFilter(Unknown Source)
            at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
            at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
            at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77)
            at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
            at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:934)
            at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:502)
            at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:179)
            at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
            at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864)
            at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
            at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
            at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
            at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
            at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
            at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
            at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
            at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
            at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
            at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
            at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
            at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
            at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
            at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
            at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
            at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604)
    
    
  • KaranBal
    KaranBal
    108 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-11-13T04:36:59Z  
    • DeanHere
    • ‏2013-11-12T13:41:17Z

    I checked some java code of PIM commands, looks like they all extending AbstractCommand. I used the getContext(); in AbstractCommand to get context instant but still error out when session is out.

    In additional, there is a PIM class RequestProcessor, 'process' method is having a session null check before processing the custom command, but not sure why it is not returning for my custom command. check the exception log below

          if (null == paramHttpServletRequest.getSession(false))
          {
            paramHttpServletResponse.sendRedirect(this.loginPage);
            return;
          }

     

    <pre dir="ltr">com.ibm.pim.common.exceptions.PIMInternalException: CWPAP0137E:No current context is available at com.ibm.ccd.api.context.DefaultContextImpl.<init>(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39) at java.lang.reflect.Constructor.newInstance(Constructor.java:527) at com.ibm.pim.context.PIMContextFactory.getCurrentContextInternal(Unknown Source) at com.ibm.pim.context.PIMContextFactory$1.initialValue(Unknown Source) at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:152) at java.lang.ThreadLocal.get(ThreadLocal.java:142) at com.ibm.pim.context.PIMContextFactory.getCurrentContext(Unknown Source) at com.ibm.ccd.ui.util.AbstractCommand.getContext(Unknown Source) at com.staples.pim.pimcore.extensionpoint.customtools.workflowdashboard.controller.WorkflowDashboardCommand.getWorkflowItems(WorkflowDashboardCommand.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.ibm.pim.web.framework.dispatcher.RequestProcessor.process(Unknown Source) at com.ibm.pim.web.framework.dispatcher.WPCControllerServlet.doProcess(Unknown Source) at com.ibm.pim.web.framework.dispatcher.WPCControllerServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1657) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1597) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:131) at com.ibm.ccd.ui.filters.FuzaoRequestFilter.doFilter(Unknown Source) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116) at com.ibm.ccd.ui.filters.ResponseHeaderFilter.doFilter(Unknown Source) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:934) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:502) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:179) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604) </pre>

    Just to recap our discussion for future reference, for the timeout setting in common.properties to apply, modify the flow-config.xml as shown below:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    Here the com.ibm.ccd.ui.util.DefaultNavigator part controls the flow and if you have that specified then the custom tool will time out just as the rest of the screens do. As mentioned in an earlier post, please change it and test. If it still doesn't time you out, then this is a potential defect but I am confident that it will.
    If you plan to use a custom command, then the normal time out will not apply and I am not sure how you would specify the timeout, maybe you will have to manually time yourself out. I am not familiar with the source code enough to know exactly what changes need to be made because of session management complications. One thing you can try is execute logout.wpcs script during the time inactivity to log the user out but that is very hard to implement and I do not recommend it. I would instead recommend that you open a PMR to confirm whether they it is possible to time out the user without the DefaultNavigator and if it is, then how. Inquiries of this sort are supported.

    Finally if you want a quick workaround without using the DefaultNavigator, then you can specify a timeout at the Websphere level. PIM runs as a business level application in the WAS container and therefore if Websphere times the user out, he would be logged out of PIM by default. Following tech note contains details on how to set the timeout in Websphere:

    http://www-01.ibm.com/support/docview.wss?uid=swg21163875

    Updated on 2013-11-13T04:42:50Z at 2013-11-13T04:42:50Z by KaranBal
  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-11-13T06:05:16Z  
    • KaranBal
    • ‏2013-11-13T04:36:59Z

    Just to recap our discussion for future reference, for the timeout setting in common.properties to apply, modify the flow-config.xml as shown below:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    Here the com.ibm.ccd.ui.util.DefaultNavigator part controls the flow and if you have that specified then the custom tool will time out just as the rest of the screens do. As mentioned in an earlier post, please change it and test. If it still doesn't time you out, then this is a potential defect but I am confident that it will.
    If you plan to use a custom command, then the normal time out will not apply and I am not sure how you would specify the timeout, maybe you will have to manually time yourself out. I am not familiar with the source code enough to know exactly what changes need to be made because of session management complications. One thing you can try is execute logout.wpcs script during the time inactivity to log the user out but that is very hard to implement and I do not recommend it. I would instead recommend that you open a PMR to confirm whether they it is possible to time out the user without the DefaultNavigator and if it is, then how. Inquiries of this sort are supported.

    Finally if you want a quick workaround without using the DefaultNavigator, then you can specify a timeout at the Websphere level. PIM runs as a business level application in the WAS container and therefore if Websphere times the user out, he would be logged out of PIM by default. Following tech note contains details on how to set the timeout in Websphere:

    http://www-01.ibm.com/support/docview.wss?uid=swg21163875

    Thanks Karan. I tested the  flow-config.xml as you mentioned and it is getting me to error page when I am opening the custom tool page, error log: No matching forward found compare with flow-config.xml and the return statement of the execute method.

    I guess its because the  flow-dispatch name="xxxWorkflowDashboard" doesn't match the execute method of DefaultNavigator, its return "success", but not "xxxWorkflowDashboard", i tested "success", its getting me to login page if session is out and I open any other pages, but still no warning popup shows, and it is not what we want.

    I will open a PMR to ask if its possible to use a custom command to do that. And will update this forum if I found a way.

  • DeanHere
    DeanHere
    9 Posts

    Re: how to set auto logout for custom tool when session timeout

    ‏2013-12-25T05:37:09Z  
    • KaranBal
    • ‏2013-11-13T04:36:59Z

    Just to recap our discussion for future reference, for the timeout setting in common.properties to apply, modify the flow-config.xml as shown below:

    <flow path="xxxWorkflowDashboard" command="com.ibm.ccd.ui.util.DefaultNavigator" method="">
    <flow-dispatch name="xxxWorkflowDashboard" location="/custom_tools/xxxWorkflowDashboard.jsp" dispatchType="forward" />

    Here the com.ibm.ccd.ui.util.DefaultNavigator part controls the flow and if you have that specified then the custom tool will time out just as the rest of the screens do. As mentioned in an earlier post, please change it and test. If it still doesn't time you out, then this is a potential defect but I am confident that it will.
    If you plan to use a custom command, then the normal time out will not apply and I am not sure how you would specify the timeout, maybe you will have to manually time yourself out. I am not familiar with the source code enough to know exactly what changes need to be made because of session management complications. One thing you can try is execute logout.wpcs script during the time inactivity to log the user out but that is very hard to implement and I do not recommend it. I would instead recommend that you open a PMR to confirm whether they it is possible to time out the user without the DefaultNavigator and if it is, then how. Inquiries of this sort are supported.

    Finally if you want a quick workaround without using the DefaultNavigator, then you can specify a timeout at the Websphere level. PIM runs as a business level application in the WAS container and therefore if Websphere times the user out, he would be logged out of PIM by default. Following tech note contains details on how to set the timeout in Websphere:

    http://www-01.ibm.com/support/docview.wss?uid=swg21163875

    got something from IBM Support/developer, 

    in JSP file, add below script:

    <%@ page import="com.ibm.ccd.common.util.StringUtils" %>
    <%@ page import="com.ibm.ccd.common.util.Configuration" %>
    <%@ page import="com.ibm.ccd.common.locale.ResourceList" %>
    <%@ page import="com.ibm.ccd.common.context.AustinContext" %>
    <script language="JavaScript">
      <%
      AustinContext ctx = AustinContext.getCurrentContext();
      // Get session timeout interval from common.properties
      int nServerTimeOutSeconds = StringUtils.checkInt(Configuration.getValue("max_inactive_interval"), 1800);out.println("nServerTimeOutSeconds:"+nServerTimeOutSeconds);
      int nWarningSeconds = nServerTimeOutSeconds/6;out.println("nWarningSeconds:"+nWarningSeconds);
      %>
      // Set global time of session activity
      parent.top.lastPostTime = (new Date()).valueOf();
      function resetSession() {
    // Compute time since last session activity
    var timeSinceLastPost = new Date().valueOf() - parent.top.lastPostTime;
    if (timeSinceLastPost >= <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>) {
     // Popup session warning message if time since last session activity greater than value in common.properties
     if (window.confirm("<%=ctx.getMessage(ResourceList.COMMON_INFO_SESSION_TIME_OUT, new Object[]{(nWarningSeconds/60)+""})%>")) {
    var f = document.reset_session_form;
    // Ping the server to keep session alive
    f.submit();
    // Set timer to recall this function
    window.setTimeout("resetSession()", <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>);
     }
    } else {
     // Set timer to recall this function
     window.setTimeout("resetSession()", <%=(nServerTimeOutSeconds-nWarningSeconds)*1000%>-timeSinceLastPost);
    }
      }
      // Start up session count down
      resetSession();
      // Reset the global time of session activity on user action (i.e. click "Search Data" button)
      function resetGlobalTimeOfSessionActivity() {
        parent.top.lastPostTime = (new Date()).valueOf();
      }
    </script>
    < iframe src='/blank.html' application=yes height=0 width=0 name=hidden_frame_for_reset_session_form></iframe>
    < form name=reset_session_form method=get target=hidden_frame_for_reset_session_form action='/blank.jsp'></form>

    still having a question that, if the session already time out, then click a button like Search Data button, still have problem.

    I cannot dig this more since I have been out.