http://coldfusion.com logo
Join Slack
Powered by
I love some of the exceptions in Lucee <https://gi...
# lucee
z
but that probably doens't need to be INFO, never stops does it
a
šŸ¤”
z
i'm gonna just change that to throw, reminds me of the problem with async logging https://luceeserver.atlassian.net/browse/LDEV-4128
b
@zackster See my comment on the ticket. I think Lucee is being too clever by second-guessing the user's intentions. This just needs to be in the docs.
There can be a reasonable use case where iterating is desirable, but security is of no concern.
z
Read the code, it's simply not supported
b
It should be
LIke I said on the ticket, the hash function does two things ā€¢ hash an input given an algorithm of your choice ā€¢ allow you to iterate X times
It's none of Lucee's business if it feels I shouldn't be iterating over a given algorithm
It's making assumptions it doesn't need to make
If a given algorithm is not considered secure, then document the secure and insecure algorithms in the docs
I don't see any reason why Lucee should be thinking for people and assuming what they want and don't want here. It just needs to do what it says "on the tin".
z
Docs already say that
b
Great, so the "fix" should be for the iterations to just work regardless of the selected algorithm šŸ™‚
z
If it doesn't do iterations, then there's nothing wrong with throwing an exception
b
But it should do iterations, no?
Unless we're saying this algorithm somehow is impossible to iterate over for some technical reason
But 
HashUtil.create64BitHashAsString()
returns a 
String
which is also what it accepts as its input, so we should be all good there
Just add in the loop so subsequent iterations act on the output of the previous one. Which would be the expected behavior.
Open in Slack
PreviousNext
Powered by