Really scratching my head on this, but I have a POST request that works well on Postman that I’m trying to replicate in KNIME. My current work flow consists of the following nodes and functions:
Table Creator
provides external URL in column 1, and specifies POST in column 2
OAuth
provides my consumer key, secret, token id, and key
HTTP Retriever
no settings modified here besides bringing “Authorization” into the inclusion section
One thing I noticed is that in the output of the Authorization text, I see HMAC-SHA1 is being specified and not HMAC-SHA256, which is what I need in my case.
I haven’t added the request body yet into this as I am looking to just get past this first part of getting OAuth working in KNIME.
Any guidance or pointers in the right direction would be greatly appreciated.
Hi @wisemanleo , as per my other post to you, you can pass this key/variable and value in the headers: oauth_signature_method="HMAC-SHA256"
I’m not sure how to pass the headers in the HTTP Retriever (it seems to read the headers from a or multiple columns from your table, but I don’t know what the format of the data should be), but from a POST Request node, you would be able to add the headers as the key/variable name and the value:
The way to use OAuth is done in 2 steps. First is to submit your Consumer key and Consumer secret to your OAuth URL, which should return you a Token. You then use that token in your POST request. Note that requesting a token for OAuth is done via a POST request, meaning that you can also do this via a POST Request node. The Palladian OAuth node is a wrapper node that helps to facilitate, sort of customizing the POST/GET request for OAuth - it actually looks like a copy of the HTTP Retriever
When you are doing your POST requests in Postman, you generate the token first, is that correct? And then submit your POST requests, is that correct?
EDIT: One thing about the Palladian OAuth is that it defaults to a GET Request. I would not send a Consumer secret, which is basically your Consumer password, over a GET Request. It will be caught in the server’s access logs since it will be converted to a query string if it’s a GET Request (meaning the secret/password will appear in the URL)
That’s not to say not to use it. Just make sure you are not sending any Consumer secret over GET, but rather POST
Some clarification about the OAuth node, as I realize that the documentation is rather scarce
The Palladian OAuth node is a wrapper node that helps to facilitate, sort of customizing the POST/GET request for OAuth - it actually looks like a copy of the HTTP Retriever
Actually, the OAuth node is not a copy of the HTTP Retriever. It acts as tool for signing requests, but it will not perform any requests itself. This is only done with the HTTP Retriever.
One thing about the Palladian OAuth is that it defaults to a GET Request. I would not send a Consumer secret, which is basically your Consumer password, over a GET Request
While the node will assume GET as default, the user has full control which HTTP method to use.
Generally, the OAuth Node is only meant for signing requests, and not for requesting any authentication credentials.
The secrets are used for signing the request and they are of course never sent in plain text. Sending such authenticated requests via GET is perfectly fine, even if they would be transmitted unencrypted and/or if requests would be logged. That’s the fundamental design idea of OAuth – a signature used once cannot be (re)used a second time (see RFC5849, section 3.3).
One thing I noticed is that in the output of the Authorization text, I see HMAC-SHA1 is being specified and not HMAC-SHA256, which is what I need in my case.
Indeed, currently we only allow SHA1 HMAC, so there’s simply no way to sign requests with other methods at the moment using the OAuth node.
I agree it would be useful to offer other signature types as well (such as SHA256). I will put this on our development backlog. However, frankly speaking I will currently not priorize this highly, as this is not exactly requested every day If you feel you need this functionality urgently and want to support the implementation of this feature, feel free to get back in touch via email.
Best regards,
Philipp
PS: For completeness: There’s also a new OAuth Connector node in Palladian. This node is for requesting authentication credentials via a browser flow (i.e. it’ll open a browser window, user enters username/password, and a tokens are returned). I just mention this to avoid any confusion – the use between both nodes is somewhat different.
I of course have tried writing “HMAC-SHA256” in the headers of the POST Request node, as well as ensuring I specify Post vs Get, but that didn’t work.
When you are doing your POST requests in Postman, you generate the token first, is that correct? And then submit your POST requests, is that correct?
My token and secrets are pre-generated in NetSuite. The only thing Postman generates (from my view) is the Nonce and Timestamp, which I think the POST Request node isn’t doing. I have tried copying Postman’s values here into the headers but that didn’t work.
I thought I saw a post elsewhere in the forum that you now do support 256. That’s too bad you don’t - that might be why I can’t get this to work.
I can only guess, but this was probably in regards to the Hash Calculator node (which is a general hashing mechanism for arbitrary content). However, that’s a separate story from the OAuth node.
Regarding further points and options to get SHA256 implemented in the OAuth node, I’ll reply to your email later.
