Hi Isomorphic,
We are trying to review the changelog to get to the bottom of other issues and we cannot seem to load the changelog for 13.1, will that be restored soon?
Thank you
Announcement
Collapse
No announcement yet.
X
-
Hi Isomorphic,
Did something change with the release notes?
That link you provided no longer has information available, it says Full release notes coming soon now.
Thanks
Last edited by stonebranch2; 12 Mar 2025, 13:27.
Leave a comment:
-
Thank you.
No worries, we applied the none option, and everything is working as expected now.
Leave a comment:
-
You can see the back compatibility release note for this change here. Just search for "storeWithHash" at the top.
Sorry we didn't document "none" originally but we were trying to promote good security practices and it was thought that "none" might be used to store plaintext passwords rather than by advanced customers like you who have developed their own hashing solution.
Leave a comment:
-
You can actually force no hash to be applied by specifying storeWithHash as "none". This has been in place since the change to use "bcrypt" by default but was undocumented.
We've now documented it and will also update the associated schema, but you don't have to wait for those changes to appear in a build to use "none".
Leave a comment:
-
Hi Isomorphic,
Do you have an update for us on this one?
Thank you
Leave a comment:
-
13.1p storeWithHash Default
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 youTags: None
Leave a comment: