Hi Isomorphic,
Did you make a change around the default behavior of password type fields with respect to storeWithHash in 13.1p?
We use a PasswordItem for a field of type password, and we are seeing the expected behavior coming from the client, but somewhere down in IDACall.handleDSRequest, the password is being hashed by default now.
We do not need the framework to do this, as we manage this ourselves.
This appears to be a change in behavior and a breaking change for us.
We tried adding storeWithHash="" in the ds.xml for the password type field, however, we get some server-side exceptions and a "MessageDigest not available" in the response.
Can you recommend what we need to do to restore the 12.1p behavior?
Thank you
Did you make a change around the default behavior of password type fields with respect to storeWithHash in 13.1p?
We use a PasswordItem for a field of type password, and we are seeing the expected behavior coming from the client, but somewhere down in IDACall.handleDSRequest, the password is being hashed by default now.
We do not need the framework to do this, as we manage this ourselves.
This appears to be a change in behavior and a breaking change for us.
We tried adding storeWithHash="" in the ds.xml for the password type field, however, we get some server-side exceptions and a "MessageDigest not available" in the response.
Can you recommend what we need to do to restore the 12.1p behavior?
Thank you