Node-RED

Digest authentication support in HttpRequest node

#1

Hi folks,

I got a question last week from a poor bastard who had bought a box full of chinese IP camera's. He could access the IP camera's from within the browser without problems. However from within a Node-RED flow (e.g. httprequest node) he received an unauthorised exception, although he entered the SAME url/username/password combination ...

I found out that his camera expected digest authentication, while the httprequest node only offers basic authentication. Here is the difference in a nutshell:

  • Basic authentication: The client sends a HTTP request with an 'authorization' header that contains the word Basic followed by a space and a base64-encoded string username:password. For example:

    Authorization: Basic ZGVtbzpwQDU1dzByZA==

    When such a request is send across an unsecure http connection, a hacker can see the username and password (by simple base64 decoding). This means a secure https connection should be used instead ...

  • Digest authentication: The client sends a HTTP request with an 'authorization' header that contains an MD5 hashed password. For example:

    Authorization: Digest username="Mufasa",
                  realm="testrealm@host.com",
                  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                  ...

    Such a password can safely be exchanged across an http connection.

Fortunately @HirokiUchikawa has recently reworked the httprequest node, to make use of the 'request' library. And that library offers digest authentication:

image

And that works fine! When I set the sendImmediately to true, the basic authentication still works on my own IP camera and the digest authentication works fine on the chinese IP camera's. Only a single line of code need to be added:

image

Some questions about this change:

  • Is this an acceptable change?
  • Does the node's config screen need to show the 'digest' somewhere?
    image

Thanks !
Bart

#2

I assume you mean false as per the screenshot?

When its sent to false, the library sends the request without any auth info attached. The 401 response it gets back from the server will include the type of auth required, so the library can resubmit the request with the appropriate auth header.

So it works, but it takes two requests over the network. So I don't think we can afford to hard code it in - by definition, all flows that successfully use auth with the node today will be penalised.

That does mean it would need to be exposed as an option in the UI, but at this point of a Friday night, I don't know what that should look like.

A tick box for 'send immediately' doesn't really help the user understand what it means - I had to read the 3 paragraphs of the request module's readme a couple times to understand what it meant.

Maybe a select box for the type of auth - which could be expanded to include Bearer (something that can be done today by setting msg.headers.authorization to the right value before the HTTP Request node). Needs more thought about what the different options mean and what they would require the node to actually do.

Announce node-red-contrib-http-logger
#3

Indeed, that was a type error... By setting it to 'false' the digest authentication works fine.

Ok, I agree with that explanation.

Have been thinking about that also, but I thought I would get lapidated when suggesting it ...