[OPENPTK-324] Internal Server Error returned from ptk:doPasswordChange
Created: 17/Feb/12 Updated: 08/May/12 Resolved: 21/Feb/12
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
openptk
Service - JNDI
2.0, 2.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Improvement
ebaustin
Fixed
None
Not Specified
Attachments:
Issue Links:
2.1
Priority:
Assignee:
Votes:
Minor
Scott Fehrman
0
Not Specified
Not Specified
RHEL 5.5 64bit, Oracle WebLogic Server 10.3.5, Oracle DSEE 11g
openptk-324-01.png
Dependency
depends on OPENPTK-325 Include error details in HTTP Response Closed
Description
Is there a way to get a more detailed ptkStatus from the JNDI context? For example, if a
doPasswordChange operation is issued, and it fails, ptkStatus is set to "Internal Server Error". A
specific example is when a user submits a password that is already in the password history. The
DSEE log has: "err=19 ... password in history". The openptk.log shows "exception:
InvalidAttributeValueException," which is valid, but is lacking the explanation string. I wrote a
test JNDI program to see the full error message, which is
javax.naming.directory.InvalidAtttributeValueException: [LDAP: error code 19 - password in
history]; remaining name 'cn=Doe John, ou=......'
Is there a way to get the "password in history" information?
Comments
Comment by Scott Fehrman [ 18/Feb/12 ]
Would you be able to provide the full openptk.log line entries related to the error? We
understand if you have to remove / mask user data. We want to make sure we're working on the
same classes.
Comment by Scott Fehrman [ 19/Feb/12 ]
I setup OpenDS 2.2.0 and enable password history with this command:
dsconfig -D "cn=directory manager" -w password -n set-password-policy-prop -policy-name "Default Password Policy" --set "password-history-count:3"
I was getting the NamingException when I tried to re-use the same password the second time. I
got the following in the openptk.log file:
SEVERE: 2012-02-18 16:52:51.040 CST: [USER:uml:jdoe:Employees-OpenDS-JNDI]
SubjectRepresentation:doPwdChange():
Context 'Employees-OpenDS-JNDI', TimeoutContext:execute():
RestartService:execute() JndiOperations:doUpdate()
entryDN='uid=jdoe,ou=people,ou=employees,dc=openptk,dc=org',
null/empty root cause, exception: OperationNotSupportedException,
I enhanced the JndIOperations class to detect the OperationNotSupportedException subclass and display its message. The Response object has its status set to this string:
entryDN='uid=jdoe,ou=people,ou=employees,dc=openptk,dc=org', [LDAP: error
code 53 - The provided new password was found in the password history for the
user]
Here is the openptk.log entry:
SEVERE: 2012-02-18 23:42:00.793 CST: [USER:uml:jdoe:Employees-OpenDS-JNDI]
SubjectRepresentation:doPwdChange():
Context 'Employees-OpenDS-JNDI', TimeoutContext:execute():
RestartService:execute() JndiOperations:doUpdate()
entryDN='uid=jdoe,ou=people,ou=employees,dc=openptk,dc=org',
[LDAP: error code 53 - The provided new password was found in the password
history for the user]
I assume that this message is what would be needed, please advise.
The default UserManagementLite sample application (used to test this issue) is still displaying
the Internal Server Error. This is because the Server is sending a generic error to the client
(UML).
Comment by ebaustin [ 19/Feb/12 ]
Yes, that's the message that is needed. I'll get you the openptk.log tomorrow. The only
difference I see in your example is that the version I'm running throws an
InvalidAttributeValueException from JNDI.
Comment by Scott Fehrman [ 19/Feb/12 ]
Checked in update to JndiOperations.java ... added check for instanceof
InvalidAttributeValueException
if (ex instanceof OperationNotSupportedException)
{
foundException = true;
}
else
{
if (ex instanceof InvalidAttributeValueException)
{
foundException = true;
}
}
Comment by ebaustin [ 19/Feb/12 ]
Forgot that I had a hardcopy with me. There maybe a few typos...
SEVERE: RestartService:execute() JndiOperations:doUpdate() entryDN='cn=Doe John,...',
Mod:2, null/empty root cause, exception: InvalidAttributeValueException, , state=ERROR,
status='entryDN='cn=Doe John,.....', Mod:2, null/empty root cause, exception:
InvalidAttributeValueException, ', attempts=1
INFO: Timestamp: 9 (msec) [TimeoutContext:execute(): [Employees-OpenDS-JNDI]
PWDCHANGE]
SEVERE: [SYSTEM:uml] SubjectRepresentation:doPwdChange(): Context 'EmployeesOpenDS-JNDI',TimeoutContext:execute(): RestartService:execute() JndiOperations:doUpdate()
entryDN='cn=Doe John,...', Mod:2, null/empty root cause, exception:
InvalidAttributeValueException,
SEVERE: [SYSTEM:uml] PasswordResource:doPwdChange: WebEngine:execute():
rep.execute(PWDCHANGE,struct): SubjectRepresentation:doPwdChange(): Context
'Employees-OpenDS-JNDI', TimeoutContext:execute(): RestartService:execute()
JndiOperations:doUpdate() entryDN='cn=Doe John,...', Mod:2, null/empty root cause,
exception: InvalidAttributeValueException,
SEVERE: [No Session] PaswordResource:execute: java.lang.Exception:
PasswordResource:doPwdChange: WebEngine:execute(): rep.execute(PWDCHANGE,struct):
SubjectRepresentation:doPwdChange(): Context 'Employees-OpenDS-JNDI',
TimeoutContext:execute(): RestartService:execute() JndiOperations:doUpdate()
entryDN='cn=Doe John,...', Mod:2, null/empty root cause, exception:
InvalidAttributeValueException,
Comment by Scott Fehrman [ 20/Feb/12 ]
UML screen shot of changes which send an Entity String from the Server to the Client. The
Entity String is then used to set the client-side "status". Previously, the status was set to the
HTTP Response code.
Comment by Scott Fehrman [ 20/Feb/12 ]
Created a Proof-of-Concept to determine if the Server-side error/warning message could be sent
to the client (JAXRS Java API).
On the Server side: Added the status to the builder as an Entity ...
status = this.getStatus(structOut);
builder.entity(status);
On the Client side: Added the Entity to the output as a String ...
entity = response.getEntity(String.class);
if (entity != null && entity.length() > 0)
{
output.setStatus(entity);
}
The UML sample application displays the status if there is an error. See the attached screen
shot.
Please comment if this PoC will meet the requirement.
Comment by ebaustin [ 20/Feb/12 ]
Yes, this is exactly what is needed. Many thanks!
Comment by Scott Fehrman [ 20/Feb/12 ]
Changed to an "improvement" ... the JNDI Operation needs to be improved to obtain more
detail and the Response sent from the Server-side to the Client-side need to support error /
warning details
Comment by Scott Fehrman [ 20/Feb/12 ]
This enhancement http://java.net/jira/browse/OPENPTK-325 is needed to transfer the serverside "status" to the client-side "status"
Comment by Scott Fehrman [ 21/Feb/12 ]
Checked in changes to JndiOperations.java which checks for sub-classes of
NamingException. This solution has been tested against OpenDS 2.2.0.
Minor updates have been made to the Context and Service classes for error handling.
Comment by Terry Sigle [ 08/May/12 ]
Tested and confirmed fixed.
Used Service OpenPTK-OpenDS-JNDI, against UnboundID DS 3.2
Generated at Tue Feb 09 10:42:40 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.