Topic
  • 2 replies
  • Latest Post - ‏2012-05-15T12:04:07Z by JMW98
chrfis
chrfis
36 Posts

Pinned topic actionPerformed not executed if user is in IDENTIFIED mode (SUA)

‏2012-05-09T10:39:39Z |
Hi,

I am running WPS 6.1.0.2 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?

Kind regards
Christian

IBM WebSphere Portal 6.1.0.2
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

Installed FixPacks:
WP_PTF_6102 (IBM WebSphere Portal, Version 6.1.0.2 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))
Updated on 2012-05-15T12:04:07Z at 2012-05-15T12:04:07Z by JMW98
  • chrfis
    chrfis
    36 Posts

    Re: actionPerformed not executed if user is in IDENTIFIED mode (SUA)

    ‏2012-05-10T07:07:13Z  
    Anybody an idea which classes I can trace to debug?
  • JMW98
    JMW98
    1139 Posts

    Re: actionPerformed not executed if user is in IDENTIFIED mode (SUA)

    ‏2012-05-15T12:04:07Z  
    • chrfis
    • ‏2012-05-10T07:07:13Z
    Anybody an idea which classes I can trace to debug?
    Start with:

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

    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:

    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Access_permissions_wp7
    (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.