I am running WPS 184.108.40.206 and have a strange behaviour.
If I authenticate using Step-Up Authentication, so user is in identified mode, no actionPerformed action phase is executed anymore.
If I am logged in as full authenticated or in anonymous state, everything works fine.
Do you have an idea why this happens?
Any filter or routine which prevents this execution in portal?
IBM WebSphere Portal 220.127.116.11
Build Level: wp6102_023_01 (2009-04-15 13:59)
Server Name: WebSphere_Portal
Started at: 5/9/2012 12:54:51:934 GMT+04:00
WP_PTF_6102 (IBM WebSphere Portal, Version 18.104.22.168 Fix Pack)
Installed Interim Fixes:
PM01429 (Deadlock during createOrWaitForConnection)
PK95611 (New PortletPreProcessor API to achieve IBM API beginPage() functionality )
PK92277 (Can't install the portlet that follows servlet 2.5 specification)
PK84300 (Friendly urls aren't working)
PK87296 (Custom ImplicitLogoutFilter fails on startup)
PK84560 (Update PSELibs.zip under /installableApps/PseLibs.zip)
PK93892 (ImplicitLoginFilter called when it is not expected)
PK87054 (ArrayIndexOutOfBoundsException while accessing friendly URL pages or anonymous pages )
PK95695 (Authentication redirect does not correctly handle selection changes (2))
Pinned topic actionPerformed not executed if user is in IDENTIFIED mode (SUA)
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-05-15T12:04:07Z at 2012-05-15T12:04:07Z by JMW98
JMW98 2000000MY61139 Posts
Re: actionPerformed not executed if user is in IDENTIFIED mode (SUA)2012-05-15T12:04:07ZThis is the accepted answer. This is the accepted answer.
- chrfis 06000209D1
and whatever traces you need to identify the request/response in your portlet (this could be as simple as com.ibm.wps.engine.*=all and looking for the doGet entry/exit). The session validation filter should fire on each request - look for:
... SessionValida < com.ibm.wps.auth.impl.SessionValidationDefaultFilter verifyAllAuthLevels RETURN ...
However, this should not interfere with actionPerformed. Portal's access controls are not this granular:
(reference: portlets on pages)
Even if this filter decided that step-up authentication were required, it should just redirect the request. If the problem is not obvious, it would probably be best to open a PMR rather than spinning your wheels on this one.