Yes you need to call the authentication flow from your node's config screen, and then Dropbox will show a few pages where you need to confirm that this Node-RED node is allowed to access your Dropbox folders. The communication to dropbox is of course SSL. So it is better if I add a bit more code to the frontend, to calculate the authentication url also there. Then I don't need to send anything to Node-RED. Of course the resulting refresh token will be send - as a credential - to Node-RED. Don't know if that can be intercepted. But that is again application level stuff, not specific to this Dropbox node.
That is no problem! I am already glad that there was some response. By thinking out loud to answer the questions, things became more clear.
Would be a shame if I introduce a security leak, while only trying to help some folks in this community...
I think I know enough for now, to continue the development.
Although one more question.
If I add a third-party code snippet to a semi-core node like this, does anybody know which licence it should have? For example found another sha256 implementation here, which has an MIT license. Is that ok to include? Perhaps something that @dceejay knows?
Oh my apologies. My mistake! By looking at your profile picture I was so certain you were one
I got something working, both with and without SSL (towards Node-RED)
But don't panic: towards Dropbox it is always SSL
When SSL is used between the flow editor and Node-RED, then I generate the SHA256 hash with the browser's Crypto Web API. Because such a hash function implementation is reviewed by experts and probably more secure.
When plain http is being used between the flow editor and Node-RED, then I generate the SHA256 hash with this implementation. Tried some others but failed to get the correct output format. That file is stored in a "resources" subfolder of the dropbox nodes, which is a standard way of working in Node-RED:
I have now removed my last endpoint in the dropbox node, which means that no data is being communicated anymore with Node-RED. I have implemented instead the logic of the Dropbox SDK generatePKCECodes inside the frontend (i.e. code verifier and code challenge calculations), so I could compose the Dropbox authentication URL myself. By removing the communication with Node-RED, I can now support both http and https traffic. Summarized:
So the only crypto data send to Node-RED (via http or https) is the refresh token at the end, to store it in Node-RED as a credential. I assume that people only use http behind a firewall. If people use this across a WAN over the internet, then I cannot help it if their refresh token gets intercepted (between their flow editor and Node-RED)...
The codebase has become very short and clean. I am very pleased with the result.
BTW I have to be honest. Have been searching like a maniac the last two evenings, why Dropbox kept complaining about "invalid code identifier". There was tiny difference between my code challenge calculation and how Dropbox calculates it. Dropbox calculates the challenge again and it must be exactly the same as mine. In my previous version I used their Javascript SDK in my endpoint, so then it was always correct. But not now that I calculate it by myself.
An hour ago I was getting desperate, and then I thought: perhaps I can ask it to the OpenAi chatbot. And I have to admit that (s)he provided me with the missing puzzle piece...
This was really too much detailed stuff after a hard dat at work. By typing the questions in my brain here and reading the doubts from other people, I finally came to a solution that I "think" is safe enough. I have tested it both on http and https.
It has become a very cryptic discussion, but it helped
About my questions I have asked to the OpenAi chatbot:
Owkay, the problem was that in an unsecure context (i.e. I was in the config screen of a flow editor that was connected to Node-RED via plain HTTP) the Web Crypto API has no digest function to calculate a SHA256 hash. Had already tried some other libraries to calculate such a hash in my browser, but the output was most of time already converted to a string. And the Web Crypto digest function returned me an arraybuffer, which was also converted by the dropbox SDK to a string. But the Dropbox SDK returned another string.
I first asked him/her "Give a javascript alternative to crypto.subtle.digest to create an sha256 hash". But that didn't work because he didn't understand "alternative", so he showed an example with the crypto.subtle.digest function (which I don't have).
Then I asked him/her "give a javascript program to create an sha256 hash in the browser without using the crypto web api", but I was not sure whether his alternative would work because he was telling that it somehow used the Web Crypto API under the hood...
Then I asked him/her "give a javascript program to create an sha256 hash in the browser when in a not secure environment". And now he gave me clear instructions which library I needed to use and a code example.
Of course you still need to know what you are doing and give him good questions. But it really helps. Although I like it, I am very sure that it will be misabused by some people in the future. But please let's not discuss that here
BTW I have to admit that first I wrote 3 times in my post "I asked him" instead of "I asked her". So although I am really a guy that likes equality between woman and man, somehow my brain thought that the OpenAi bot was male . So my sincere apologies to all the ladies on this blue planet for me thinking that a chatbot with high quality technical answers can only be male.
Ok hopefully the ladies accept my apologies. Although I wonder if any of them will ever read a cryptic technical discussion like this. Damn now my brain did it again