Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-7667

Decrypting/Encrypting hide fields value that are not set as encrypted when click on custom button on Maintenance Document

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.1.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KNS
    • Application Requirement:
      KFS, Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      In rice maint docs , when click on custom button it is decrypting/encrypting value of hide fields that are not set as encrypted and causing
      RuntimeException that The field value for field name " + fieldName + " should be encrypted.".

      If the field value is not set it works fine. The KualiMaintainableIml.shouldFieldBeEncrypted() method should need to skip those fields.

      KFS needs this fix for one of their kfscntrb jira for release5.0.

        Attachments

          Issue Links

            Activity

            Hide
            jksmith James Smith added a comment -

            Added Kevin Kronenbitter as a watcher.

            We are going to carry out an experiment early next week on how AttributeSecurity for "hide" works. We believe that if the "hide" attribute security is not present, then the business object authorizer will not be called to check if view maint doc or inquiry field permission exists (and if the current user is granted that permission).

            If that's the case then here's where we are:

            • if you do not have the permission, then the field should not show up, even as a <input type="hidden" on the page (it would be nice to verify this).
            • if you do have the permission then the field is available for viewing and possibly editing. If it's view only, is there an input type="hidden" with an encrypted variable?

            ...and then the question becomes whether we really meant to use this AttributeSecurity on the KFS side or not.

            Show
            jksmith James Smith added a comment - Added Kevin Kronenbitter as a watcher. We are going to carry out an experiment early next week on how AttributeSecurity for "hide" works. We believe that if the "hide" attribute security is not present, then the business object authorizer will not be called to check if view maint doc or inquiry field permission exists (and if the current user is granted that permission). If that's the case then here's where we are: if you do not have the permission, then the field should not show up, even as a <input type="hidden" on the page (it would be nice to verify this). if you do have the permission then the field is available for viewing and possibly editing. If it's view only, is there an input type="hidden" with an encrypted variable? ...and then the question becomes whether we really meant to use this AttributeSecurity on the KFS side or not.
            Hide
            jruch Jeff Ruch added a comment -

            Pending response from KFS.

            Show
            jruch Jeff Ruch added a comment - Pending response from KFS.
            Hide
            gilesp Peter Giles (Inactive) added a comment -

            Hi Shannon, I'm giving this one to you. Since the other parties are at IU, maybe you can use the sneakernet to figure out where we are

            Show
            gilesp Peter Giles (Inactive) added a comment - Hi Shannon, I'm giving this one to you. Since the other parties are at IU, maybe you can use the sneakernet to figure out where we are
            Hide
            jksmith James Smith added a comment -

            Lucky, lucky Shannon!

            Show
            jksmith James Smith added a comment - Lucky, lucky Shannon!
            Hide
            shahess Shannon Hess added a comment -

            James & Megha,

            Thanks for meeting with me today. This issue has been fixed (in the 2.1.3-SNAPSHOT code), and it actually turned out to be a bug in the KualiMaintainableImpl.decryptEncryptedData method. I noticed that the encryption error was being thrown on conditionCode, which is not a hidden field for either bomiddle or gshaugh (Land Information fields are hidden for gshaugh). In KualiMaintainableImpl.decryptEncryptedData, there is a variable called auths, which contains all of the fields that are currently hidden. In my testing scenario, the Land Information fields are in the hidden fields list for gshaugh but not for bomiddle, and conditionCode is never in the hidden fields list. Before the error was thrown, there was no check to see if the field being evaluated was in the list of currently hidden fields, it just checked to see if was a field that should have been encrypted.

            So I added the following to the if check, which corrects the problem:

            Old if check:

            else if (fieldValue != null && !"".equals(fieldValue)
                && shouldFieldBeEncrypted(maintenanceDocument, fieldName, auths, methodToCall))
                   throw new RuntimeException("The field value for field name " + fieldName + " should be encrypted.");
            

            Updated if check:

            else if (fieldValue != null && !"".equals(fieldValue)
                && auths.hasRestriction(fieldName)
                && shouldFieldBeEncrypted(maintenanceDocument, fieldName, auths, methodToCall))
                   throw new RuntimeException("The field value for field name " + fieldName + " should be encrypted.");
            

            auths.hasRestriction checks to see if the field is a read only field, a partially masked field, a fully masked field, or a hidden field. Since the fields causing the error are not in the list of hidden fields at the time, it's not restricted and returns false. (if the field does happen to be a ready only field, the shouldFieldBeEncrypted field returns false so that is not an issue.)

            If you could bring in the latest 2.1.3 code and test this out on your side as well that would be great.

            Thanks!
            Shannon

            For my own reference:

            To test and verify fields are hidden -

            • backdoor as bomiddle
            • Do an Asset search and edit one of them
            • Hit the "Update Last Inventory Date" button to verify no errors occur
            • The "Land Information" fields should be visible.
            • Enter in values for all of these fields and submit the document. (verify it gets processed)
            • backdoor as gshaugh
            • Do an Asset search and edit the same asset
            • Hit the "Update Last Inventory Date" button to verify no errors occur
            • The "Land Information" fields NOT should be visible.
            • Change something on the document and submit it document. (verify it gets processed)
            • backdoor as bomiddle
            • Do an Asset search and edit the same asset
            • The "Land Information" fields should be visible and the data entered the first time should still be there.
            Show
            shahess Shannon Hess added a comment - James & Megha, Thanks for meeting with me today. This issue has been fixed (in the 2.1.3-SNAPSHOT code), and it actually turned out to be a bug in the KualiMaintainableImpl.decryptEncryptedData method. I noticed that the encryption error was being thrown on conditionCode, which is not a hidden field for either bomiddle or gshaugh (Land Information fields are hidden for gshaugh). In KualiMaintainableImpl.decryptEncryptedData, there is a variable called auths, which contains all of the fields that are currently hidden. In my testing scenario, the Land Information fields are in the hidden fields list for gshaugh but not for bomiddle, and conditionCode is never in the hidden fields list. Before the error was thrown, there was no check to see if the field being evaluated was in the list of currently hidden fields, it just checked to see if was a field that should have been encrypted. So I added the following to the if check, which corrects the problem: Old if check: else if (fieldValue != null && !"".equals(fieldValue) && shouldFieldBeEncrypted(maintenanceDocument, fieldName, auths, methodToCall)) throw new RuntimeException( "The field value for field name " + fieldName + " should be encrypted." ); Updated if check: else if (fieldValue != null && !"".equals(fieldValue) && auths.hasRestriction(fieldName) && shouldFieldBeEncrypted(maintenanceDocument, fieldName, auths, methodToCall)) throw new RuntimeException( "The field value for field name " + fieldName + " should be encrypted." ); auths.hasRestriction checks to see if the field is a read only field, a partially masked field, a fully masked field, or a hidden field. Since the fields causing the error are not in the list of hidden fields at the time, it's not restricted and returns false. (if the field does happen to be a ready only field, the shouldFieldBeEncrypted field returns false so that is not an issue.) If you could bring in the latest 2.1.3 code and test this out on your side as well that would be great. Thanks! Shannon For my own reference: To test and verify fields are hidden - backdoor as bomiddle Do an Asset search and edit one of them Hit the "Update Last Inventory Date" button to verify no errors occur The "Land Information" fields should be visible. Enter in values for all of these fields and submit the document. (verify it gets processed) backdoor as gshaugh Do an Asset search and edit the same asset Hit the "Update Last Inventory Date" button to verify no errors occur The "Land Information" fields NOT should be visible. Change something on the document and submit it document. (verify it gets processed) backdoor as bomiddle Do an Asset search and edit the same asset The "Land Information" fields should be visible and the data entered the first time should still be there.

              People

              • Assignee:
                shahess Shannon Hess
                Reporter:
                mramawat Megha Doshi
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: