[OPENIDM-13740] Explicit repo table: validate mapping before CREATE Created: 03/Sep/19  Updated: 23/Jul/20  Resolved: 23/Jul/20

Status: Closed
Project: OpenIDM
Component/s: _Schema, Module - Policy, Module - Repository JDBC
Affects Version/s: 7.0.0, 6.5.0.1
Fix Version/s: 7.0.0, 6.5.0.3

Type: Bug Priority: Major
Reporter: Jesse Ontiveros Assignee: Travis Haagen
Resolution: Fixed Votes: 0
Labels: CLARK, Customer, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IDM 6.5.0.1, SQL repo with explicit mapping


Issue Links:
Relates
is related to OPENIDM-14066 Recon status report showed extra reco... Closed
Target Version/s:
Verified Version/s:
QA Assignee: Brayden Roth-White Brayden Roth-White
Story Points: 3
Sprint: 2019.14 - IDM
Support Ticket IDs:

 Description   

1) . Set up IDM 6.5.0.1 with SQL repo and explicit mapping

2).  Set disable openidm.policy.enforcement.enabled in boot.properties

3).  Make sure to restart

4).  import in a user using REST:

POST  http://localhost:8080/openidm/managed/user/?_action=create

payload:

{ "userName": "FR-asdfasdf", "givenName": "ForgeRock", "sn": "BNS", "password": "Welcome1", "mail": "test.user1@example.com", "preferences" : "ABC" }

 

Results:

{ "code": 500, "reason": "Internal Server Error", "message": "Unable to map JSON_MAP value for preferences" }

 
While we understand that disabling openidm.policy.enforcement.enabled allows REST to pass any type of data, what is happening is that this data is getting written to the repo.  If a customer see the 500 internal server error, they cannot correct the payload and update the repo.  They have to remove the data from the backend in order to correct their situation.  We should not be writing data to the repo when we get a 500 error like this.
 
Looks like openidm.policy.enforcement.enabled​ acts on all parts of the managed object's attribute, e.g. type​, whereas from the documentation, it should only act on the policies​.
 



 Comments   
Comment by Brendan Miller [ 05/Sep/19 ]

Regardless of the policy setting, the repo should not store data and return a 500. Additionally, if the input is invalid, a 400 should be returned.

Comment by Travis Haagen [ 14/Oct/19 ]

FIXED: Added validation to prevent the wrong JSON data-type from being persisted in an explicit-schema table for relational databases. An error will be returned before the data is persisted now, whereas before the invalid data was only detected on read.

Comment by Michal Orlik [ 17/Jan/20 ]

 6.5.0.3-672c742

Before:

curl --header "X-OpenIDM-Username: openidm-admin" --header "X-OpenIDM-Password: openidm-admin" --header "Content-Type: application/json" --data '{ "userName": "FR-asdfasdf", "givenName": "ForgeRock", "sn": "BNS", "password": "Welcome1", "mail": "test.user1@example.com", "preferences" : "ABC" }' --request POST "http://localhost:8080/openidm/managed/user/?_action=create"

Response Content:
{"code":500,"reason":"Internal Server Error","message":"Unable to map JSON_MAP value for preferences"}

After:

curl --header "X-OpenIDM-Username: openidm-admin" --header "X-OpenIDM-Password: openidm-admin" --header "Content-Type: application/json" --data '{ "userName": "FR-asdfasdf", "givenName": "ForgeRock", "sn": "BNS", "password": "Welcome1", "mail": "test.user1@example.com", "preferences" : "ABC" }' --request POST "http://localhost:8080/openidm/managed/user/?_action=create"

Response Content:
{"code":400,"reason":"Bad Request","message":"Invalid value for field: /preferences"}
Comment by Brayden Roth-White [ 14/Feb/20 ]

Verified 7.0.0-SNAPSHOT 36fa9fc – Automation added to PyForge

Comment by Lana Frost [ 23/Jul/20 ]

Reopening to add to release notes

Generated at Sun May 09 06:50:14 UTC 2021 using Jira 8.16.0#816000-sha1:a455b91378454416b49bbc88d03e653cb9815ed5.