From what I can tell right now there's no plans for adding HMAC to our freemarker utilities. But that might change if there's a better understanding for the customer needs.
Can you elaborate a bit how that support would be beneficial for Lithium customers? I'm having a hard time imagining scenarios where you would apply two way hashing when using Lithium APIs.
ClaudiusH thanks for the reply.
Yes, I can give you the general use-case, but I suggest reading up on HMAC vs. one-way hashing in established mobile app frameworks, in relation to it, since that will establish the usefulness of HMAC vs. either one-way hashes or say, a larger-keyspace'd pubkey/asymmetric approach (see https://en.wikipedia.org/wiki/Hash-based_message_authentication_code , and i.e. https://www.dropbox.com/s/jb9mqvfdcbi6fx2/Screenshot%202017-04-06%2012.57.40.png?dl=0 ).
Since "mobile" in this context means we are loading a Lithium-responsive site through XHR in a hybrid-mobile shell , we require a round-trip transport to hold secure state, irregardless of Lithium user-state in the DOM load.
This sort of user-stateless -but-state-necessitating interaction is common in hybrid-mobile, where hashes of deviceID's are in URL parameters, for communicating with that given user's phone OS. I.e. specifically, since the integration is time/latency-sensitive and URL query dependent, HMAC is the tool of choice.
Hope that helps! In the screenshot posted above, our basic assumption on the necessity of HMAC check out according to the use-case, as elaborated on here. Again, thanks for your reply...
Kind Regards,
Paul
santhoshsampath Thanks for the context and sorry for not following up earlier. There is some good news to share though: The release notes for 17.4 include new HMAC methods on utils.digest. This should be useful for your scenario. Please talk to your Lithium contact to ensure your community gets slated for the upgrade early.
