# Node-RED behind Reverse Proxy auth issue

**URL:** https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065
**Category:** General
**Created:** [10 February 2022 03:00 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065 "2022-02-10T03:00:43Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![bubus](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bubus/32/44356_2.png) [@bubus](https://discourse.nodered.org/u/bubus)
#### Post date: [10 February 2022 03:00 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065/1 "2022-02-10T03:00:43Z")

</div>

Hello all,

Running Node-RED behind reverse proxy that does not point to subdomain (for example _[nodered1.server.com](http://nodered1.server.com)_) but to specific path like _[server.com/nodered1](http://server.com/nodered1)_ causes auth issues (and maybe more).

When I open _[server.com/nodered1](http://server.com/nodered1)_, enter my credentials and click login my browswer is redirected to _[server.com/?access\_token=asdf](http://server.com/?access_token=asdf)_ which is wrong. Expected behaviour should be to redirect to _[server.com/nodered1/?access\_token=asdf](http://server.com/nodered1/?access_token=asdf)_

Is there any workaround for that?

One solution (not sure if stupid or clever 😃 ) might be to look at the Referer header and comparing it with httpAdminRoot before doing res.redirect().

Or maybe it can be somehow done in other way?

---

<div class="post-metadata">

### Author: ![hardillb](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hardillb/32/12373_2.png) [@hardillb](https://discourse.nodered.org/u/hardillb)
#### Post date: [10 February 2022 14:41 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065/2 "2022-02-10T14:41:36Z")

</div>

Before you go any further down this route even once you get authentication to work for a single instance, you need to know that you can't run more than one instance this way. e.g. `www.example.com/nodered1` and `www.example.com/nodered2` because the editor currently stores it's access token in browser local storage which is only scoped to the hostname, not the hostname + path.

The solution to the first problem probably to include a rewrite option in your reverse proxy settings. Can you post what your proxy config and is it Nginx, Apache or Traefik?

---

<div class="post-metadata">

### Author: ![bubus](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bubus/32/44356_2.png) [@bubus](https://discourse.nodered.org/u/bubus)
#### Post date: [10 February 2022 16:07 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065/3 "2022-02-10T16:07:03Z")

</div>

> editor currently stores it's access token in browser local storage which is only scoped to the hostname, not the hostname + path.

Ye but I do not need to be logged in to two instances at once. If token is invalid login dialog will pop out.

I figured out easy solution for my problem. It is to expose httpAdminRoot in the same path as in reverse proxy and everything works.

Proxy Apache config that works (treat it like a PoC):

```auto
ProxyPassMatch "/node-red/(([^\/]*)(?=[\/]))/(.*)" "http://svc-nodered-$1.nodered-test.svc:8080/node-red/$1/$3"
ProxyPassReverse "/node-red/(([^\/]*)(?=[\/]))/(.*)" "http://svc-nodered-$1.nodered-test.svc:8080/node-red/$1/$3"

```

In this scenario proxied path is /node-red/{tenant} and httpAdminRoot is also set to /node-red/{tenant}

---

<div class="post-metadata">

### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [10 February 2022 17:35 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065/4 "2022-02-10T17:35:45Z")

</div>

There is at least 1 setting in Node-RED that tells it to trust the proxy, you may need to do that.

Otherwise, use your proxy to do authentication, not node-red. This is likely to be more flexible, and powerful anyway and creates a nice separation of concerns between node-red and the proxy.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)
#### Post date: [11 April 2022 17:36 UTC](https://discourse.nodered.org/t/node-red-behind-reverse-proxy-auth-issue/58065/5 "2022-04-11T17:36:36Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
