Bug 533052 - Exceptions incorrectly return requestStatus == SUCCESS
Summary: Exceptions incorrectly return requestStatus == SUCCESS
Keywords:
Status: CLOSED EOL
Alias: None
Product: Dogtag Certificate System
Classification: Retired
Component: Certificate Manager
Version: 1.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: RHCS Maintainers
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 688231
TreeView+ depends on / blocked
 
Reported: 2009-11-04 20:09 UTC by John Dennis
Modified: 2020-03-27 20:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 20:04:17 UTC
Embargoed:


Attachments (Terms of Use)
patch (2.21 KB, patch)
2009-11-12 15:51 UTC, John Dennis
no flags Details | Diff

Description John Dennis 2009-11-04 20:09:02 UTC
The requestStatus value is set to SUCCESS when an unexpectedError exception occurs. Since the requestStatus value is used to determine the outcome of the request the receiver will not recognize that the result was actually not successful as reported, but rather an exception occurred. As it stands now the only way to detect an exception is to ignore the requestStatus value and look for the presence of fixed.unexpectedError.

Here is how this happens:

in CMSServlet.service a new CMSRequest object is created, it's status (e.g. mStatus) is initialized to SUCCESS. It is assigned to the cmsRequest variable.

The cmsRequest object is passed to the servlet's process() method. If an exception occurs while in the process() method control returns immediately to the catch block for EBaseException, which then passes the same cmsRequest object to renderException().

renderException then calls the getTemplateParameters() method from the GenUnexpectedErrorTemplateFiller class passing the same cmsRequest object. It gets the status from the cmsRequest object via getStatus(), which since it's never been modified since the object was created is still SUCCESS. So it inserts a requestStatus value of SUCCESS into the CMSTemplateParams it will subsequently returns.

CMSServlet.renderException() and GenUnexpectedErrorTemplateFiller.getTemplateParameters() should probably both force the status to CMSRequest.EXCEPTION by calling cmsRequest.setStatus(CMSRequest.EXCEPTION) since by the time either of these routines are called it's a given the status should be CMSRequest.EXCEPTION no matter what the current value of CMSRequest.mStatus is.

Comment 1 John Dennis 2009-11-12 15:51:55 UTC
Created attachment 369241 [details]
patch

Comment 2 Andrew Wnuk 2009-11-18 00:45:13 UTC
attachment (id=369241) +awnuk

It looks to me that that renderException() set request status to CMSRequest.EXCEPTION before getTemplateParams() is called.
Is there any reason set request status again inside getTemplateParams()?

Comment 3 John Dennis 2009-11-18 16:59:10 UTC
Re comment #2. This is a good observation. In the current calling sequence resetting the status is redundant. However, also assuring it's set in getTemplateParams() is defensive programming in the service of robustness in case a different code path is taken for some reason.


Note You need to log in before you can comment on or make changes to this bug.