For the input value :
--------------------------
test
test
--------------------------
The online tool at https://www.dcode.fr/sha256-hash generates:
HEX: 5222d2759616f0cb5795ff2b345204a9bf40d9b6fa01f6670290a4958f81a5a9
Whereas the "Generate Security Hash" assertion generates:
HEX: 72EF1BCD7A4D61B0DBF76327DBFFA77E245BB020210A90C06F0BA388BF235E3A
API Gateway 9.X
https://www.dcode.fr/sha256-hash provides one answer while another online tool https://hash.online-convert.com/sha256-generator gives the same answer as the "Generate Security Hash" assertion.
After printing out the raw characters being hashed, we find that the assertion does not ignoring the OA or OD characters. If the EOL character is OA, we get the match of the hash for the first tool. If the EOL is CR/LF, we get a match on the hash for the second tool.
So the difference between the hashes is due to different EOL characters in the raw input data.
The options selected in the Set Context Variable assertion provide 2 options:
a) CR/ LF
b) LF
We found that the online tool was generating hash using LF, whereas the default for the Set Context Variable assertion was CR/LF.
Once we changed the Context Variable Properties to use LF as the EOL character, we matched the hash256 value from the website.
Printing out the hex of the input values is useful for debugging to determine exactly what value (LF and CR and all ) is being hashed.
Printing the hex value of the raw data that is being hashed is a helpful way to determine which non-visible characters are being used - notably here the CR and CR LF characters which are OD and OD OA in hex.
Results using CR/LF :
Results using LF :