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 Bug Fix
    • Status: Closed Closed
    • Priority: Critical 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
    • Similar issues:
      KULRICE-7688Decrypting/Encrypting hide fields value that are not set as encrypted when click on custom button on Maintenance Document
      KULRICE-3850Person maintenance document encrypts the encrypted tax ID value when user can't see it
      KULRICE-8412Fields encrypted on URL are not always decrypted when returned to document
      KULRICE-7637show inactive / hide inactive button on subtab is not working correctly.
      KULRICE-10439AttributeSecurity hide attribute is not handled correctly
      KULRICE-5313Lookup doesn't return properly when clicking "return" button
      KULRICE-10641Maintenance document missing show/hide inactive button when collection implements Inactivatable
      KULRICE-4760Buttons on forms no longer have tabindex values
      KULRICE-9076Fix Criteria Masking on Lookups with encrypted fields
      KULRICE-5431Customized Post Data-load Encryption
    • 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.

        Issue Links

          Activity

          Hide
          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
          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
          Jeff Ruch added a comment -

          Pending response from KFS.

          Show
          Jeff Ruch added a comment - Pending response from KFS.
          Hide
          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
          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
          James Smith added a comment -

          Lucky, lucky Shannon!

          Show
          James Smith added a comment - Lucky, lucky Shannon!
          Hide
          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
          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:
              Shannon Hess
              Reporter:
              Megha Doshi
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel