HTTP IN with Cookies and Multi-Part

[John O'Connor]

Hey there,

I'd like to add HTTP multi-part form support and cookie parsing to the HTTP IN node and wanted to get your take on it.

***** cookie parsing *****

I understand there's concern with adding sessions in particular.  My implementation does not create sessions, but instead just adds cookie parser middleware to each request.  This makes session support possible and is something that is currently very difficult to do.  Session support with the existing system is very difficult because the developer needs to manually manage the HTTP headers with function nodes.

The cookie-parser middleware is minimally invasive because it only affects specifically the cookie headers and doesn't appear to impact any other fields of the header or the body of a request or response.  I've added this capability to my local httpIn nodes and have not experienced issues in a wide array of manual tests I've been doing.

https://github.com/node-red/node-red/commit/035ffefd5a2a23e02f2bef0f79b0471cd813429f?diff=unified

I'd be ok with making this optional but considering it's impact is very small and there are other, far more invasive, middleware that is currently not optional (see below) I think it would be an unnecessary complication to require the cookie-parser option to be something that needs to be enabled with options.

****** Multi-Part *****

This was very tricky to implement because the body-parser middleware that comes bundled with the current HTTP node mangles multi-part requests and generally makes them impossible to perform.   Body-parser has to be disabled for multi-part form parsing to work in express.

I have created a modified Multi-Part HTTP IN node that allows for multi-part form submissions and supports file uploading.

https://github.com/sax1johno/node-red-contrib-http-multipart

I've found requests for this feature more than a few times in various discussion boards while I was searching for a way to do file uploads using the bundled HTTP IN node.

The implementation I have now could be adapted to the built-in HTTP-IN node making this separate node obsolete.  The major change would be that the body-parser middleware would need to be deferred until the form type and encoding is determined.  I'd be happy to make this change and provide unit tests to verify.

Thanks,

John

[Nicholas O'Leary]

Hi John,

file upload is very much on the todo list - we'd welcome your input.

The cookie parsing is also worth looking at. We would definitely have to be careful in adding it - we must ensure it doesn't break any existing flows - it is quite likely that there will be flows out there that do use a Function node to handle the cookies (as unideal as that is). We would need to understand if they would be impacted at all by adding the parser in.

By the way, it is easy to add additional middleware using the httpMiddleware option in settings.js - I've seen that used for cookie parsing before. But I can see the benefit of having it baked in.

Whilst we're here, I'm also looking at how we can improve the authentication story around the HTTP In nodes. Currently you can set all-or-nothing basic auth via the settings file. I'm thinking about what we can do on a per-node basis, and what options we ought to provide out of the box (Basic auth, bearer token etc) and how it may be extensible (passport etc)

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[John O'Connor]

 

file upload is very much on the todo list - we'd welcome your input.

Ok awesome.  File upload was a requirement for a project I'm doing so I created a separate HTTP-IN node that just handles the multi-part form parsing.  I'll work on integrating it into HTTP-IN and run some tests to make sure it doesn't break anything.

I used multer in my own implementation and it seems to work pretty well.  I think the design of the node itself could use some work (at this point it just passes through a JSON object) but I've been putting it through the ringer on a project and it seems to be holding up.  The big issues is that body-parser interferes with and mangles multi-part form requests so it has to be disabled before you can process files.

 

The cookie parsing is also worth looking at. We would definitely have to be careful in adding it - we must ensure it doesn't break any existing flows - it is quite likely that there will be flows out there that do use a Function node to handle the cookies (as unideal as that is). We would need to understand if they would be impacted at all by adding the parser in.

Hmm - do you guys have any automated tests for flows or suggestions for a technique?  I'd be interested in setting up some tests to see if adding CookieParser breaks anything.  From my work on other express projects cookie-parser seems to be minimally impactful but useful middleware.  Aside from the modification it makes to the response and request nodes adding cookie management methods, it doesn't have any impact on any other part of the HTTP requests or responses.  I tested it just now with a function node that modifies the cookie header and the cookie-parser didn't seem to affect it at all.

 

By the way, it is easy to add additional middleware using the httpMiddleware option in settings.js - I've seen that used for cookie parsing before. But I can see the benefit of having it baked in.

Yea - I started out using something like that at first but felt that cookie parsing was a feature worthy of being added.  Right now the body-parser and a few other middleware are set as defaults and I know body-parser is a very invasive middleware.

Whilst we're here, I'm also looking at how we can improve the authentication story around the HTTP In nodes. Currently you can set all-or-nothing basic auth via the settings file. I'm thinking about what we can do on a per-node basis, and what options we ought to provide out of the box (Basic auth, bearer token etc) and how it may be extensible (passport etc)

That's very interesting.  I put together an authentication node based on passport but was having trouble getting session to work in a decent way.  Sessions were really tricky to implement in a node without breaking other stuff.

I ended up going with a JsonWebToken(JWT) and am really happy with it.  For API calls I can just pass the JWT into the request via the "access_token" body or querystring parameter and for sessions I'm just setting a cookie and storing the JWT there.  Since the JWT is encrypted there's no need to use any other session middleware.  Also, the code you use to validate the token is the same no matter where the token comes from.

I put together a module that can be dropped into a flow to generate or verify JsonWebTokens:

https://github.com/sax1johno/node-red-contrib-auth

It checks for a token on the msg.payload, so if you make an API call you can just include the token as a parameter to the request (querystring or body).  For non-api calls and calls that render pages to a browser, I have one extra function node that retrieves the token from the cookies and puts it on the payload.  The difference between authenticating an API and authenticating a web call is a single function node with 2 lines of code:

msg.token = msg.req.cookie("access_token");

return msg;

I thought it was pretty elegant - it allows the developer to choose any method they desire to authenticate the user and the JWT just stores the user data.  I should have an example using passport (without sessions) put together in the next few days.

[John O'Connor]

file upload is very much on the todo list - we'd welcome your input.

I should mention that the multi-part node handles file upload.

[Julian Knight]

Whilst we're here, I'm also looking at how we can improve the authentication story around the HTTP In nodes. Currently you can set all-or-nothing basic auth via the settings file. I'm thinking about what we can do on a per-node basis, and what options we ought to provide out of the box (Basic auth, bearer token etc) and how it may be extensible (passport etc)

Do you really need per node authentication? Wouldn't per path auth be fine? Could you explain the use cases for per-node auth?

Basic auth is always handy to have as it is the lowest common denominator but it is really only useful for test/dev cases as it isn't very secure for live. Bearer tokens can be good but require some careful thoughts on implementation so that they actually provide assurance and cannot be bypassed/hijacked (MiTM hijacking is a common problem). JWT is a nice, simple implementation but isn't really enough on its own. Passport is pretty much the standard implementation for node.js authentication and immediately gives you access to a great many useful libraries including Azure, Google, Facebook, Twitter, etc cloud authentications.

Of course, with all of these, you still have to maintain a secure "database" of acceptable identifiers unless you want anyone with a cloud id to be able to get access. With JWT and other self-serve authentication methods, you will need something to manage both the id and the secured hash of the password. This is likely to need it's own admin UI, possibly a user UI too if you want users to be able to sign up for themselves. As you already have something in place for securing the admin UI, you could build on that.

All of this needs HTTPS wire encryption too otherwise it's pretty pointless.

It is complex but it would really lift Node-Red up towards something that is a lot more robust and production ready. It would be great to see. Personally, I wouldn't reinvent the wheel. Although getting started may be a little more complex with Passport, the eventual benefits would, I think, be well worth it.

 

That's very interesting.  I put together an authentication node based on passport but was having trouble getting session to work in a decent way.  Sessions were really tricky to implement in a node without breaking other stuff.

I ended up going with a JsonWebToken(JWT) and am really happy with it.  For API calls I can just pass the JWT into the request via the "access_token" body or querystring parameter and for sessions I'm just setting a cookie and storing the JWT there.  Since the JWT is encrypted there's no need to use any other session middleware.  Also, the code you use to validate the token is the same no matter where the token comes from.

I put together a module that can be dropped into a flow to generate or verify JsonWebTokens:

https://github.com/sax1johno/node-red-contrib-auth

It checks for a token on the msg.payload, so if you make an API call you can just include the token as a parameter to the request (querystring or body).  For non-api calls and calls that render pages to a browser, I have one extra function node that retrieves the token from the cookies and puts it on the payload.  The difference between authenticating an API and authenticating a web call is a single function node with 2 lines of code:

msg.token = msg.req.cookie("access_token");

return msg;

I thought it was pretty elegant - it allows the developer to choose any method they desire to authenticate the user and the JWT just stores the user data.  I should have an example using passport (without sessions) put together in the next few days.

Of interest, how do you prevent man-in-the-middle hijacking of the token?

[John O'Connor]

Thanks for the responses guys.

I'll address in two parts:

First, adding cookie-parsing to the HTTP-in node is a general concept.  It's a requirement to do the kind of cookie-based authentication that I'd like to do, but not related to authentication per-se.  It'd be required for passport-based auth as well.

I tested it out myself with modified HTTP-in nodes and added function nodes that added and parsed cookies.  When I added a cookie with the function node, it was available in the cookie-parser on the next call.  When I added a cookie with cookie-parser, I was able to parse it with a function node and extract that cookie.  I'll send the flow here shortly - I think it demonstrates that cookie-parser can be safely added without affecting existing nodes.

The retrieving of cookies in particular is really challenging and error prone so if anything that's why I'd like to see it make the trip upstream.

Second, I'll address authentication in particular and Julian's comments (thank you for your thoughtful response btw).

Whilst we're here, I'm also looking at how we can improve the authentication story around the HTTP In nodes. Currently you can set all-or-nothing basic auth via the settings file. I'm thinking about what we can do on a per-node basis, and what options we ought to provide out of the box (Basic auth, bearer token etc) and how it may be extensible (passport etc)

I think HTTP-in should not have auth built into it.  Instead, we should use HTTP-in as the interface and add an authentication mechanism after the HTTP-in node.

 

Some context: I'm using node-red to wire up web-based microservices, so my flow looks like the following:

HTTP-In ->  Auth -> Microservice -> HTTP-out

By doing it this way I can make MicroService calls through other channels - HTTP is just an interface to the service itself.

I could also do:

OtherMechanismIn -> Auth -> microservice -> OtherMechanismOut

The OtherMechansimIn flow can pass a JWT in on the payload and now I have authentication that is not coupled to web-based techniques.  It can use OAuth tokens, can be placed in a Bearer Token, etc.

In a general case I think a node for auth makes a lot of sense - it decouples the auth mechanism from the interface used to access it (which is the reason I use node-red).

Basic auth is always handy to have as it is the lowest common denominator but it is really only useful for test/dev cases as it isn't very secure for live. Bearer tokens can be good but require some careful thoughts on implementation so that they actually provide assurance and cannot be bypassed/hijacked (MiTM hijacking is a common problem).

Not to be contrarian but basic auth is useless even for development.   The only case for using it is to secure a resource, and you don't secure a resource that isn't live or publicly available unless your testing your authentication flows.  You can't use it to test authentication flows because it doesn't allow you to easily clear the authentication credentials.  In every case where you'd use basic auth, you'd be better off keeping it on a local server and not exposing the resource the the public at all until your authentication system is ready.

Bearer-token is great for API-type calls where you can add the token to the headers of every request, but they don't work for browser-based environments where the authentication information needs to persist across page loads.  This requires the use of a cookie - hence my desire to add cookie-parser to the HTTP-in node.

 

JWT is a nice, simple implementation but isn't really enough on its own. Passport is pretty much the standard implementation for node.js authentication and immediately gives you access to a great many useful libraries including Azure, Google, Facebook, Twitter, etc cloud authentications.

 

JWT is just a secure way to store information client-side with cookies.  I was able to use facebook and passport (without sessions) and subsequently save the facebook access_token into a JWT for later use.  The nice thing about using JWT is that you can use it where something like passport isn't appropriate (ie: an API endpoint secured by an access token).  The same mechanism (JWT) can be used to authenticate both web-based endpoints using passport or API endpoints with a developer-generated access token.

Passport itself is something I'll address further down, but suffice it to say that the requirements of passport are very intrusive as you have to add custom middleware to the express route to get it working.  With a generalized HTTP-in node, you either have to have this middleware applied all the time, or set an option to enable / disable it.  I actually did both of these and found it to be very complicated.  With JWT, it became almost unnecessary.

Of course, with all of these, you still have to maintain a secure "database" of acceptable identifiers unless you want anyone with a cloud id to be able to get access. With JWT and other self-serve authentication methods, you will need something to manage both the id and the secured hash of the password.

That's a general requirement for authentication systems.    You have to store user ID's and crypted / salted passwords somehow with passport-local too. I don't see this as an argument against JWT - JWT is just concerned with storing data in a secure way.

 

This is likely to need it's own admin UI, possibly a user UI too if you want users to be able to sign up for themselves.

Same thing as above - that's a requirement for passport as well.  It doesn't provide a UI for you - it just has some methods that make authentication via various methods a little easier.  You still have to do all the work of storing the credentials and even figuring out how to secure them.

 

As you already have something in place for securing the admin UI, you could build on that.

Mine is a web form that sends credentials to a user microservice for authentication.  The microservice returns back the user info and permissions which are stored in a JWT and stored in a cookie.  That's the flow you'll have to use for any auth system, but replace "microservice" with whatever you're doing to secure your user (facebook, local, etc).  

All of this needs HTTPS wire encryption too otherwise it's pretty pointless.

This is just a requirement for any secure system anyway.  Of note is that, even over HTTP, the data in the JWT is still cryptographically secure.  Without SSL it just makes that token useless as a secret for authentication.  You can still store data in it safely though.

It is complex but it would really lift Node-Red up towards something that is a lot more robust and production ready. It would be great to see. Personally, I wouldn't reinvent the wheel. Although getting started may be a little more complex with Passport, the eventual benefits would, I think, be well worth it.

I actually started the http-node-contrib-auth module as a passport node (check out dat commit history) and I'll probably take that work and branch it into a new http-node-contrib-passport module. It allowed you to configure a strategy and install new strategies, as well as control the authenticate middleware entirely within node-red (no custom httpNodeMiddleware needed).

I moved away from a passport-based implementation as the foundation of node-red auth for many reasons:

• The HTTP-in node needs to be modified to support the passport.authenticate() middleware in the express chain.
• You could do this with custom middleware in the settings.js file but this takes away the "drag and drop" ability for the node to work. If you add the "auth-passport" node, you'd still need to modify your configuration to make it work.   At that point you lose the benefit of node-red - you could just drop the entire thing express and call it a day.  Drag-and-drop into the flow is what makes node-red so awesome and I wanted a solution that kept this.
• passport is a PAIN without session support and sessions required a massive overhaul with intrusive middleware applied to the entire application.  JWT makes sessions possible in a non-intrusive way.
• Passport and sessions would still require the cookie-parser middleware to be on HTTP-in anyway so either way this is still useful.

Passport is great for connect/express apps and it's multiple strategy design is VERY elegant, but it's designed for use with express and it definitely shows.  It's tightly coupled with the concept of routes, middleware, and (to an extent) the express-sessions package.   It's meant to be easy to get started, but it's not a robust system that can realistically be decoupled from express apps.  For flow-based programming, we need a fundamentally different approach (authenticating on flows instead of middleware).  

You'd be better off taking the passport design and creating a new authentication system that specifically targets flow-based applications (we could still use passport strategies though which would be really cool).  That might be my next project.

After all that, for a web-based user you still have the problem of storing authentication data on the client or the user has to log into every page.  That means either sessions (which passport uses) or some other cryptographically secure cookie (ie: a JWT or something similar).  JWT gives us a way to store cookies within a flow-based environment.

Of interest, how do you prevent man-in-the-middle hijacking of the token?

The only way to prevent MITM effectively is to use HTTPS.  This is just a general requirement - nothing specific to JWT or authentication. When you add cookie you can use the secure=true and httpOnly=true options to make sure you're functionally safe from MITM and XSS attacks on the cookie itself.

[Nicholas O'Leary]

John, thanks for your detailed mail. It is helping me think through the various options.

Cookies

I absolutely agree that we need to make it easier to work with cookies - that isn't in doubt. We do have a long standing goal to get to the point where messages are entirely JSON encodable between nodes. The fact we exposed the HTTP req/res objects directly on msg was, in hindsight, a mistake. Adding cookie-parser will just mean msg.req.cookies will be a plain object contain the cookies - no other impact, so it _should_ be perfectly safe.

The main inhibitor we have to messages being JSON encodable are the functions hanging off msg.res. We need to define message properties that can be used in lieu of calling those functions, so that the HTTP Response node can call them on the flow's behalf. The cookie() function is one such function to work around.

HTTP Auth

I'm in two minds about whether the auth belongs in the HTTP node or a subsequent node. I can see the point you're making about enabling auth from other sources, but even if we added http-specific methods to the HTTP nodes, you'd still be able to do authentication downstream of the node.

As for what auth mechanisms we offer - it is important that we don't get too prescriptive. Node-RED is a development platform and needs to be flexible - I know of specific requirements around bearer token and basic auth for example. A JWT approach should definitely be on the list.

I would like to see what we can do to make it easy to create an app that, for example, uses Twitter for auth - ie any auth scheme that involves a 3rd party challenge/response flow. There's lots to pick through there around the multiple routes needed to support that type of thing, along with sessions etc. Passport is an underlying implementation detail - whether we use it or not should have no bearing on how this functionality is exposed to the user.

Nick

--

[Julian Knight]

NOTE: I've written the following over the last day or so. I apologise that it has gotten rather rambling and maybe a little confused as I worked through it all in my head. I decided to post it anyway in the hopes that at least some of it is useful. Please read to the end before tearing me to shreds! :-}

I'm in absolute agreement that Passport is fairly heavyweight and is complex compared to JWT. However, I think these are slightly different tools. Indeed there is a JWT extension for Passport for this reason. 

Of course we need to be careful not to confuse JWT with an authentication mechanism. JWT only provides the token. You still need to 

1. Authenticate - e.g. log in. A process which creates the initial token.
2. Validate - the token must be validated server side to ensure that it hasn't been intercepted and been used in a replay attack. To do this successfully requires (I think, I'm a little hazy on this) some maintenance of state on the server (which JWT claims to avoid but as far as I can see, it really doesn't if you want to avoid possible playback attacks). A simple mechanism might be to record the browsers local IP address for example which would allow the server to prevent (well mainly) the use of the token from another machine - something which has been used repeatedly as an attack vector in the real world. Reducing the time to live of tokens also helps here but again, auto-renewal of tokens needs to be carefully done to make sure that you validate you are still talking directly to the original client.

All of the recommendations for using JWT only mention using TLS as a secure transport layer to prevent MITM attacks but this is actually a rather suspect approach on its own. TLS itself is notoriously difficult to get right and keep right and there are several well documented methods that make use of shortcuts commonly taken by both browsers and servers to undo the theoretical security of TLS encrypted transports. The lack of validation of full certificate paths for example. The weaknesses of HTTPS are well documented which is why things like SPDY and certificate pinning have appeared to try and improve things.

We are entering deep territory here and I reiterate that it is difficult to get this right and all too easy to end up with something that looks secure but isn't. If possible, it would make sense to call on some specific expertise to get this right, maybe there is someone in IBM who could advise? I know the issues, I don't know all the specifics of getting it right, I'm an IT person really, not a developer.

I'm sure that providing a JWT mechanism would be useful but it isn't a complete solution. Passport with appropriate plugins can be a complete solution but it is complex - and it needs to be, secure comms is a complex thing.

One other thing. John mentioned that you need cookies for session management and I'm afraid this isn't correct. Indeed, you cannot rely on cookies partly because they may be disabled by the user and also because, at least on public services to the EU, you have to then also provide notification and opt-out to users. Session management is easily done without cookies, especially if you are happy to have the session terminate with the browser (so only in-memory storage is required).

Having given this further thought this weekend, I'm actually wondering if it wouldn't be better to start with a good write-up of how to secure Node-Red from the outside rather than trying to make things fit internally?

I would normally recommend that node.js apps should only be connected to the internet via a front-end reverse proxy server such as NGINX which would make a better job overall of securing access to node with the added advantage of having a consolidated security configuration for multiple web interfaces - potentially even across multiple machines. In addition, coupling NGINX (or Apache, LightHTTP or IIS even) with Phusion Passenger is even better. There are many advantages of a front-end server as it can easily be configured to protect from a variety of attacks.

Although this approach still requires an authentication mechanism, that could be handled as an independent micro-service and integrated to the reverse proxy. NGINX for example has the excellent ngx_http_auth_request_module that will automatically redirect to a login page (which could be a separate node.js or other platform microservice) if it receives a 401 response from the app server. This is much more "the node way" of keeping things simple and focused. Perhaps a few people could work up a reference implementation.

Alternatively, perhaps providing the simple cookie handler node (which Nick has already said he knows needs doing) along with a simple JWT handler node (with appropriate caveats and warnings) would be good. This would enable people to build some level of authentication/authorisation into their flows quite easily and would still allow or indeed encourage the full security infrastructure to be built in something more focused as outlined above.  OK, so I think I'm rambling now and have probably just gone round in circles so I best give up here.

Anyway, just call me an old worry-wart but the complexity of getting security right could easily be a distraction from the many other initiatives you could work on for Node-Red.

[John O'Connor]

On Saturday, April 30, 2016 at 1:54:14 PM UTC-7, Nick O'Leary wrote:

John, thanks for your detailed mail. It is helping me think through the various options.

For sure :) I've become a huge fan of node-red and have integrated into a lot of my own work.  It's a great project so anything I can do to help.

 

Cookies

I absolutely agree that we need to make it easier to work with cookies - that isn't in doubt. We do have a long standing goal to get to the point where messages are entirely JSON encodable between nodes. The fact we exposed the HTTP req/res objects directly on msg was, in hindsight, a mistake. Adding cookie-parser will just mean msg.req.cookies will be a plain object contain the cookies - no other impact, so it _should_ be perfectly safe.

The main inhibitor we have to messages being JSON encodable are the functions hanging off msg.res. We need to define message properties that can be used in lieu of calling those functions, so that the HTTP Response node can call them on the flow's behalf. The cookie() function is one such function to work around.

I see what you're saying.  I personally don't have a problem with the msg object containing other methods and not being JSON encodeable.  Having access to the request and response objects within the flow makes certain tasks much easier, and most of the time I'm putting data itself in the msg.payload anyway.

That said, perhaps having a path context in addition to a flow and global context might be a way to get there?

HTTP Auth

I'm in two minds about whether the auth belongs in the HTTP node or a subsequent node. I can see the point you're making about enabling auth from other sources, but even if we added http-specific methods to the HTTP nodes, you'd still be able to do authentication downstream of the node.

As for what auth mechanisms we offer - it is important that we don't get too prescriptive. Node-RED is a development platform and needs to be flexible - I know of specific requirements around bearer token and basic auth for example. A JWT approach should definitely be on the list.

I would like to see what we can do to make it easy to create an app that, for example, uses Twitter for auth - ie any auth scheme that involves a 3rd party challenge/response flow. There's lots to pick through there around the multiple routes needed to support that type of thing, along with sessions etc. Passport is an underlying implementation detail - whether we use it or not should have no bearing on how this functionality is exposed to the user.

Yes, I agree.  I think any answer to authentication isn't going to be a built-in - it'll be a flow rather than a node.  Even using passport the developer still has to configure routes to capture the tokens and kick off the auth flow. 

In my case the auth stuff was all actually really easy.  I was able to implement login / password and OAuth login with just a few basic nodes and it works fine.  The only problem I actually had was server-side session support and I was able to solve that with JWT and cookies.

I'll publish the flow once I'm done with testing it - perhaps it'll be helpful in the general discussion.

Thanks :)

[Librae]

Hello John,

I went through this thread and find your words:

> The only problem I actually had was server-side session support and I was able to solve that with JWT and cookies.

Have you find a proper solution for this?

In my case it was similar and I haven't find an easy solution yet, to put it simple, I'd like to build a simple web app with Node-RED in which people can register their accounts and see different content after login.

I'd appreciate that if you can share your flow to manage user accounts and sessions.

Thanks,

Librae

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

[John O'Connor]

Hello Librea,

Sure - I actually wrote this up in an article for IBM:

https://www.compose.com/articles/authenticating-node-red-with-jsonwebtoken/

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/NVDi0ko-qs0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/CAGQqdCKLs5MVDaSWmim_QJQo_w%2BhCQFb82sCB%3DLdSTnJRexQ7w%40mail.gmail.com.