Hello Database gurus,
We recently upgraded from Forms & Reports 10.1 to 12.2.1.2, and our database from 10.1 to 12.2 as well. Our application seems to be working fine. However, our 60-day password reset policy (mandated by FISSMA) is now expiring passwords, and no one can use the application "Change Password" form.
Our Change Password form follows all the documentation recommendations I can find in researching Oracle website -- 3 user-entry text boxes for "Old Password", "New Password", "Confirm Password", with triggers on each to ensure "Old" is not null, "Old" = Get_Application_Property(PASSWORD), and "New" = "Confirm". These PRE- and POST-TEXT-ITEM triggers are successfully being passed, but the user receives a "Password not changed" message, with ORA-28008: Invalid old password upon clicking [Save]. From all the example code I've found for Forms & changing password, our form matches the code shown. It worked fine in 10g, but no one has been able to change their password after the original (successful) password reset.
This doesn't make sense, because the POST-TEXT-ITEM trigger on "Old" = Get_Application_Property(PASSWORD) is verifying they are equal. I've even entered garbage in the "Old" field to test, and it correctly identifies when "Old" <> Get_App...(PWD) before reaching the [SAVE] button error detection code. The actual mechanism to reset the password is as follows:
alter_stmt := 'ALTER USER '||:USERNAME||' IDENTIFIED BY "'||:CONFIRM_PASSWORD||'" REPLACE "'||:OLD_PSWD_ENTERED||'"';
FORMS_DDL(alter_stmt);
Usera are triggering the IF NOT Form_Success validation block after executing the FORMS_DDL statement, and receiving our own "...password not changed." message, followed by the ORA:28008 oracle DMBS_ERROR_TEXT.
We did convert the 10g to 12c passwords in our new Database 12.2.0.1 database for all users. We reset each user's password to a default, and everyone has been able to use this Change Password form to reset their password from the default. Now that their first "personal" password is expiring, no one can change their password before it expires. I'm suspecting this may be database-centric, so I'm posting this here, as well as in the Forms forum. In any event our Change Password form will have to interface correctly with the new 12c password restrictions/criteria in the database.
Entering the above alter_stmt at the SQLplus prompt with all variables substituted as appropriate, works as expected -- it's simply not working when passed through the FORMS_DDL mechanism.
Has anyone else experienced this problem and found a resolution? I am unable to find any similar issues in the Forms forum, and in the Oracle knowledge base, and we are in danger of all users not having access within the next 2 days due to expiring passwords.
Thank you for your assistance!