Fix (APAR): PK14211 Status: Fix Release: 5.1.1.7,5.1.1.6,5.1.1.5 Operating System: AIX,HP-UX,Linux,Linux Red Hat - pSeries,Linux zSeries,Solaris,Windows Supersedes Fixes: CMVC Defect: PK10334 Byte size of APAR: 5887 Date: 2005-11-22 Abstract: Receive 404 error when POST to ibm_security_logout servlet Description/symptom of problem: PK14211 resolves the following problem: ERROR DESCRIPTION: Forms based logout is misinterpreting the value for name="logoutExitPage". An absolute value is being specified (http://hostname.business.com/weblogin/logout) but it is being converted to a URL relative to the to the application context root, (/myapp/http://hostname.busness.com/weblogin/logout) This causes the browser to issue "404 page not found". - If the logout is done by a call to the special URI "ibm_security_logout" with request parameter logoutExitPage set to an absolute URL this worked with WAS 6.0.1. That is, after the logout from WAS the browser was redirected to the specified (absolute) logoutExitPage URL. Example (logout button in application html page):
- After the POST to ibm_security_logout the browser is redirected to: http://hostname.business.com/weblogin/logout - With WAS 6.0.2 this has changed. It obviously treats the value of logoutExitPage always as a relative URI. That means, relative to the to the application context root. Example: Assuming the context root of the application is "/myapp/" the above sample will return a redirect to the URL /myapp/http://hostname.business.com/weblogin/logout Of course that doesn't work and produces a "404 page not found" on the browser. - The change in processing was introduced in APAR PQ97264. - Looking for a way to specify an absolute URL as the LogoutExitPage value. LOCAL FIX: PROBLEM SUMMARY USERS AFFECTED: WebSphere Application Server security users with Form Logout Exit pages PROBLEM DESCRIPTION: Receive 404 error when POST to ibm_security_logout servlet RECOMMENDATION: None When POST to ibm_security_logout servlet, you may get 404 error if Logout exit page is not relative URI. This is caused by a previous APAR, which enforce all logout exit page be relative URI to Context root. PROBLEM CONCLUSION: Since there is no spec for the logout exist page, lot of existing applications do not follow the relative URI rule. We will allow the flexibility on logout page when com.ibm.websphere.sendredirect.compatibility is set to false. 1. if logout exit page starts with /, it is a relative URI by default. 2. if logout exit page starts with /, and the system property, com.ibm.websphere.security.web.absoluteUri is set to "true", the logout exit page is treated as absolute URI. 3. if logout page does NOT start with /, it will not be treated as a relative URI, For example, if logout page starts with http:// or https://, it is absolute URL, and WebSphere security will use as it is to call sendRedirect . The fix for this APAR is currently targeted for inclusion in fixpack 6.0.2.3. Please refer to the Recommended Updates page for delivery dates: http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP &uid=swg27004980 Directions to apply fix: NOTE: Choose the: 1) Release the fix applies to 2) The Editions that apply 3) Delete the Editions & Methods that do not apply and this Note Fix applies to Editions: Release: 5.0 5.1 ___ ___ Application Server (Express or BASE) ___ Enterprise Edition (DD) ___ ___ Network Deployment (ND) ___ ___ Edge Components ___ ___ Developers Edition ___ ___ Tools ___ WebSphere Business Integration Server Foundation (WBISF) Install Fix to: Method: __ Application Server Nodes __ Deployment Manager Nodes __ Both NOTE: The user must: * Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * Be logged in with the same authority level when unpacking a fix, fix pack or refresh pack. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 The Update Installer for V5.0 does not have a maintenance directory. It uses fixpacks and fixes as the location of the unpacked files. 1) Copy PKxxxxx.jar file directly to the maintenance directory 2) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Select the "Install maintenance package" operation. 6) Enter the file name of the maintenance package to install (PKxxxxx.jar file which was copied in the maintenance directory). The V5.0 and V5.1 fix packs and fixes are unpacked as .jar files and should be unpacked into fixpacks or fixes directory. 7) Install the maintenance package. 8) Restart WebSphere Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (PKxxxxx.jar). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere. Additional Information: