[GH-ISSUE #1319] Auth_request module not behaving as expected with Organizr

kerem commented

2026-02-26 06:35:34 +03:00

Owner

Originally created by @nathanakalish on GitHub (Aug 15, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1319

Describe the bug
When using Nginx's auth_request module in Nginx v2.9.6, the authentication behaves as expected. When updating to v2.9.7, the module does not redirect to the given subdirectory. Subdomains seem to always work fine. Authentication is using Organizr and tested by @causefx

Nginx Proxy Manager Version
Working: 2.9.6
Not Working: 2.9.7

To Reproduce

Set up an auth_request under a subdirectory to authenticate a page in NPM 2.9.6 (NPM JSON.txt)
Visiting the webpage should work normally if authenticated, and fail with a 401 error if not authenticated.
Update to 2.9.7
Make any change to the proxy host configuration for the page that is to be protected to force NPM to reload the file.
Visit the page with subdirectory again and it fails to load properly with the error:
Page Error.txt

Expected behavior
subdirectory page should load the same in 2.9.6 and 2.9.7

Operating System
Docker Container via Unraid

Originally created by @nathanakalish on GitHub (Aug 15, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1319 **Describe the bug** When using Nginx's auth_request module in Nginx v2.9.6, the authentication behaves as expected. When updating to v2.9.7, the module does not redirect to the given subdirectory. Subdomains seem to always work fine. Authentication is using [Organizr](https://github.com/causefx/Organizr) and tested by @causefx **Nginx Proxy Manager Version** Working: 2.9.6 Not Working: 2.9.7 **To Reproduce** 1. Set up an auth_request under a subdirectory to authenticate a page in NPM 2.9.6 ([NPM JSON.txt](https://github.com/jc21/nginx-proxy-manager/files/6987438/NPM.JSON.txt)) 2. Visiting the webpage should work normally if authenticated, and fail with a 401 error if not authenticated. 3. Update to 2.9.7 4. Make any change to the proxy host configuration for the page that is to be protected to force NPM to reload the file. 5. Visit the page with subdirectory again and it fails to load properly with the error: [Page Error.txt](https://github.com/jc21/nginx-proxy-manager/files/6987437/Page.Error.txt) **Expected behavior** subdirectory page should load the same in 2.9.6 and 2.9.7 **Operating System** Docker Container via Unraid

kerem

2026-02-26 06:35:34 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 06:35:34 +03:00

Author

Owner

@nathanakalish commented on GitHub (Aug 22, 2021):

Clicked the wrong button and accidentally closed the issue.

@nathanakalish commented on GitHub (Aug 22, 2021): Clicked the wrong button and accidentally closed the issue.

kerem commented

2026-02-26 06:35:34 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 3, 2021):

Had same issue. When using 2.9.9 was working, when updated to 2.9.11, experienced the exact issue you were.

@muddro1 commented on GitHub (Nov 3, 2021): Had same issue. When using 2.9.9 was working, when updated to 2.9.11, experienced the exact issue you were.

kerem commented

2026-02-26 06:35:34 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

Same issue, can provide logs if needed

@ChronoStriker1 commented on GitHub (Nov 3, 2021): Same issue, can provide logs if needed

kerem commented

2026-02-26 06:35:34 +03:00

Author

Owner

@chaptergy commented on GitHub (Nov 3, 2021):

Not sure if I would even be able to help, but I don't really understand the issue, to be specific what the Page Error.txt should mean. What exactly is the error that occurs? Where does it occur? In the browser? Is it returned by some network request? Is it an error in the npm logs? Host logs?
Could any of you describe what exactly the error is? If you have any helpful additional information like logs, that's probably very useful, too.

@chaptergy commented on GitHub (Nov 3, 2021): Not sure if I would even be able to help, but I don't really understand the issue, to be specific what the `Page Error.txt` should mean. What exactly is the error that occurs? Where does it occur? In the browser? Is it returned by some network request? Is it an error in the npm logs? Host logs? Could any of you describe what exactly the error is? If you have any helpful additional information like logs, that's probably very useful, too.

kerem commented

2026-02-26 06:35:34 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 3, 2021):

Not sure if I would even be able to help, but I don't really understand the issue, to be specific what the Page Error.txt should mean. What exactly is the error that occurs? Where does it occur? In the browser? Is it returned by some network request? Is it an error in the npm logs? Host logs? Could any of you describe what exactly the error is? If you have any helpful additional information like logs, that's probably very useful, too.

So essentially, we all utilize organizr for auth services. Prior to the update, the setup was similar to the NPM JSON in OP, and it worked in requireing any proxy host to authenticate with organizr before providing access. After the update, it appears after providing said credentials, NPM would return the JSON in the Page Error.txt file instead of redirecting to the appropriate proxy host.

@muddro1 commented on GitHub (Nov 3, 2021): > > > Not sure if I would even be able to help, but I don't really understand the issue, to be specific what the `Page Error.txt` should mean. What exactly is the error that occurs? Where does it occur? In the browser? Is it returned by some network request? Is it an error in the npm logs? Host logs? Could any of you describe what exactly the error is? If you have any helpful additional information like logs, that's probably very useful, too. So essentially, we all utilize organizr for auth services. Prior to the update, the setup was similar to the NPM JSON in OP, and it worked in requireing any proxy host to authenticate with organizr before providing access. After the update, it appears after providing said credentials, NPM would return the JSON in the Page Error.txt file instead of redirecting to the appropriate proxy host.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

Possibly unrelated, if I try and edit one of the services that I use this auth with and then change it back, I now get 500 Internal server errors with the console saying:
Failed to load resource: the server responded with a status of 500 () service.domain.org/:1
For the time being to get past both issues, I have had to resort to setting basic auth in NPM, which is not ideal.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): Possibly unrelated, if I try and edit one of the services that I use this auth with and then change it back, I now get 500 Internal server errors with the console saying: Failed to load resource: the server responded with a status of 500 () service.domain.org/:1 For the time being to get past both issues, I have had to resort to setting basic auth in NPM, which is not ideal.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@DoubtfulTurnip commented on GitHub (Nov 3, 2021):

I have managed to work around the issue by moving the auth block for organizr from the location tab to the advanced tab in NPM

location ~ ^/auth-(.*) {
        ## Has to be local ip or local DNS name or if Proxied use proxy address
        proxy_pass http://organizr:80/api/v2/auth?group=$1;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        }

Like a lot of people I was following the IBRACORP instructions on getting Organizrs auth block setup in NPM. This worked until a recent update in NPM and I have since had to apply the workaround.

Essentially I have followed the IBRACORP guide exactly the same but have moved all the location tab settings to the advanced tab.

https://ibracorp.io/server-auth-organizr-nginx-proxy-manager/

@DoubtfulTurnip commented on GitHub (Nov 3, 2021): I have managed to work around the issue by moving the auth block for organizr from the location tab to the advanced tab in NPM ``` location ~ ^/auth-(.*) { ## Has to be local ip or local DNS name or if Proxied use proxy address proxy_pass http://organizr:80/api/v2/auth?group=$1; proxy_pass_request_body off; proxy_set_header Content-Length ""; } ``` Like a lot of people I was following the IBRACORP instructions on getting Organizrs auth block setup in NPM. This worked until a recent update in NPM and I have since had to apply the workaround. Essentially I have followed the IBRACORP guide exactly the same but have moved all the location tab settings to the advanced tab. https://ibracorp.io/server-auth-organizr-nginx-proxy-manager/

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@DoubtfulTurnip commented on GitHub (Nov 3, 2021):

Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting.

Not sure if this is anything to do with it but did you remember to also add the auth block for organizr itself but using the block as per the instructions. The block is slightly different.

location ~ ^/auth-(.*) {
proxy_pass http://organizr:80/api/v2/auth?group=$1;
proxy_set_header Content-Length "";
internal;
 }

This is just a wild guess though and may not be related to your issue.

@DoubtfulTurnip commented on GitHub (Nov 3, 2021): > > > Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting. Not sure if this is anything to do with it but did you remember to also add the auth block for organizr itself but using the block as per the instructions. The block is slightly different. ``` location ~ ^/auth-(.*) { proxy_pass http://organizr:80/api/v2/auth?group=$1; proxy_set_header Content-Length ""; internal; } ``` This is just a wild guess though and may not be related to your issue.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting.

Not sure if this is anything to do with it but did you remember to also add the auth block for organizr itself but using the block as per the instructions. The block is slightly different.
location ~ ^/auth-(.*) {
proxy_pass http://organizr:80/api/v2/auth?group=$1;
proxy_set_header Content-Length "";
internal;
 }
This is just a wild guess though and may not be related to your issue.

Yep, its been like that (proxy_pass address is the difference) since prior to version 2.9.6 of NPM.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): > > Me trying the above workaround is how I found I am now getting the 500 error. Happens with it set or after reverting. > > Not sure if this is anything to do with it but did you remember to also add the auth block for organizr itself but using the block as per the instructions. The block is slightly different. > > ``` > location ~ ^/auth-(.*) { > proxy_pass http://organizr:80/api/v2/auth?group=$1; > proxy_set_header Content-Length ""; > internal; > } > ``` > > This is just a wild guess though and may not be related to your issue. Yep, its been like that (proxy_pass address is the difference) since prior to version 2.9.6 of NPM.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 3, 2021):

My setup has been slightly different but essentially the same as I followed organizr's instructions from their documentation. If there was any difference, it was working on 2.9.9. Main thing is the proxy pass went to : organizrv2/api/v2/auth/$1.

https://docs.organizr.app/features/server-authentication/nginx-server-authentication

@muddro1 commented on GitHub (Nov 3, 2021): My setup has been slightly different but essentially the same as I followed organizr's instructions from their documentation. If there was any difference, it was working on 2.9.9. Main thing is the proxy pass went to : organizrv2/api/v2/auth/$1. https://docs.organizr.app/features/server-authentication/nginx-server-authentication

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

For S's and G's I have updated my settings to the current organizr documentation for a test and I still get a 500 error.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): For S's and G's I have updated my settings to the current organizr documentation for a test and I still get a 500 error.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@chaptergy commented on GitHub (Nov 3, 2021):

Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the /app/templates/_location.conf file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run apt update && apt install nano, and then use nano to edit the file.

Replace line 2 with the following very similar line:

    set              $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};

Then go ahead and edit the proxy host and save, to regenerate the config file.

@chaptergy commented on GitHub (Nov 3, 2021): Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the `/app/templates/_location.conf` file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run `apt update && apt install nano`, and then use `nano` to edit the file. Replace line 2 with the following very similar line: ```nginx set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; ``` Then go ahead and edit the proxy host and save, to regenerate the config file.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 3, 2021):

Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the /app/templates/_location.conf file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run apt update && apt install nano, and then use nano to edit the file.

Replace line 2 with the following very similar line:
    set              $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};

I would assume after the change this file, they need to edit the proxy (add a comment or something) to trigger NPM to rebuild the proxy file..?

@causefx commented on GitHub (Nov 3, 2021): > Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the `/app/templates/_location.conf` file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run `apt update && apt install nano`, and then use `nano` to edit the file. > > Replace line 2 with the following very similar line: > > ```nginx > set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; > ``` I would assume after the change this file, they need to edit the proxy (add a comment or something) to trigger NPM to rebuild the proxy file..?

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@chaptergy commented on GitHub (Nov 3, 2021):

Yes, that's correct, sorry I forgot to mention that

@chaptergy commented on GitHub (Nov 3, 2021): Yes, that's correct, sorry I forgot to mention that

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

I've attempted this but still get the 500, I will restore an older config backup (one that I had the actual stated issue in op) later in case the changes I have made today have broken something.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): I've attempted this but still get the 500, I will restore an older config backup (one that I had the actual stated issue in op) later in case the changes I have made today have broken something.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 3, 2021):

I dont have the error 500 that Chrono is getting, but none-the-less, it did not work for me.

@muddro1 commented on GitHub (Nov 3, 2021): I dont have the error 500 that Chrono is getting, but none-the-less, it did not work for me.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 3, 2021):

After restoring my config and making that change, and then making a change to a host Im back to the original error.

@ChronoStriker1 commented on GitHub (Nov 3, 2021): After restoring my config and making that change, and then making a change to a host Im back to the original error.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 3, 2021):

Looked at _location.conf of 2.9.9 and replaced that line 2 with what was in there (set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }};) but didnt work either

@muddro1 commented on GitHub (Nov 3, 2021): Looked at _location.conf of 2.9.9 and replaced that line 2 with what was in there (`set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }};`) but didnt work either

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 3, 2021):

I'm gna set my test server back up and will test this.

@causefx commented on GitHub (Nov 3, 2021): I'm gna set my test server back up and will test this.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 3, 2021):

Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the /app/templates/_location.conf file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run apt update && apt install nano, and then use nano to edit the file.

Replace line 2 with the following very similar line:
    set              $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};
Then go ahead and edit the proxy host and save, to regenerate the config file.

the edit that i did:

[root@docker-npm:/app]# cat /app/templates/_location.conf | grep unless
    set              $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};

Edit:

spoke too soon. while it doesn't error 500, it goes back to displaying api instead of the page.

@causefx commented on GitHub (Nov 3, 2021): > Okay, it might have to do with the move to a variable with the proxy pass directive. Try the following, edit the `/app/templates/_location.conf` file inside the container. You can do this however you wish, but you could for example connect a shell to the container and run `apt update && apt install nano`, and then use `nano` to edit the file. > > Replace line 2 with the following very similar line: > > ```nginx > set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; > ``` > > Then go ahead and edit the proxy host and save, to regenerate the config file. This workaround worked for my testing on version `v2.9.11 © 2019 jc21.com` the edit that i did: ``` [root@docker-npm:/app]# cat /app/templates/_location.conf | grep unless set $upstream {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; ``` Edit: spoke too soon. while it doesn't error 500, it goes back to displaying api instead of the page.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 3, 2021):

@chaptergy i did some more testing... While your edit does help set the upstream to not include the request_uri variable, the problem is 100% due to using the upstream variable in the proxy_pass directive. Why? I'm not sure... If I manually comment out the upstream variable and replace with what the variable was assigned with minus the request_uri variable all will work as expected. I will do some more testing.

@causefx commented on GitHub (Nov 3, 2021): @chaptergy i did some more testing... While your edit does help set the upstream to not include the request_uri variable, the problem is 100% due to using the upstream variable in the proxy_pass directive. Why? I'm not sure... If I manually comment out the upstream variable and replace with what the variable was assigned with minus the request_uri variable all will work as expected. I will do some more testing.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 3, 2021):

@chaptergy I see exactly what the issue is now. We need to use a different variable name instead of upstream

I renamed it to : upstreamHost

location ~ /organizr-auth/(.*) {
    set              $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

and everything worked correctly. So renaming it from upstream to anything else - such as upstreamHost and setting your work around to remove the request_uri variable will fix this.

I edited /app/templates/_location.conf to this:

  location {{ path }} {
    set              $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

    {% if access_list_id > 0 %}
    {% if access_list.items.length > 0 %}
    # Authorization
    auth_basic            "Authorization required";
    auth_basic_user_file  /data/access/{{ access_list_id }};
 
    {{ access_list.passauth }}
    {% endif %}
 
    # Access Rules
    {% for client in access_list.clients %}
    {{- client.rule -}};
    {% endfor %}deny all;
 
    # Access checks must...
    {% if access_list.satisfy %}
    {{ access_list.satisfy }};
    {% endif %}
 
    {% endif %}

    {% include "_assets.conf" %}
    {% include "_exploits.conf" %}

    {% include "_forced_ssl.conf" %}
    {% include "_hsts.conf" %}

    {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %}
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    {% endif %}


    {{ advanced_config }}
  }

@causefx commented on GitHub (Nov 3, 2021): @chaptergy I see exactly what the issue is now. We need to use a different variable name instead of `upstream` I renamed it to : `upstreamHost` ``` location ~ /organizr-auth/(.*) { set $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1; proxy_set_header Host $host; proxy_set_header X-Forwarded-Scheme $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_pass $upstreamHost; ``` and everything worked correctly. So renaming it from `upstream` to anything else - such as `upstreamHost` and setting your work around to remove the `request_uri` variable will fix this. I edited `/app/templates/_location.conf` to this: ```nginx location {{ path }} { set $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; proxy_set_header Host $host; proxy_set_header X-Forwarded-Scheme $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_pass $upstreamHost; {% if access_list_id > 0 %} {% if access_list.items.length > 0 %} # Authorization auth_basic "Authorization required"; auth_basic_user_file /data/access/{{ access_list_id }}; {{ access_list.passauth }} {% endif %} # Access Rules {% for client in access_list.clients %} {{- client.rule -}}; {% endfor %}deny all; # Access checks must... {% if access_list.satisfy %} {{ access_list.satisfy }}; {% endif %} {% endif %} {% include "_assets.conf" %} {% include "_exploits.conf" %} {% include "_forced_ssl.conf" %} {% include "_hsts.conf" %} {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %} proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; {% endif %} {{ advanced_config }} } ```

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@muddro1 commented on GitHub (Nov 4, 2021):

@causefx's solution worked for me

@muddro1 commented on GitHub (Nov 4, 2021): @causefx's solution worked for me

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@ChronoStriker1 commented on GitHub (Nov 4, 2021):

Can confirm that worked for me as well

@ChronoStriker1 commented on GitHub (Nov 4, 2021): Can confirm that worked for me as well

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@dirtymike0330 commented on GitHub (Nov 4, 2021):

@chaptergy I see exactly what the issue is now. We need to use a different variable name instead of upstream

I renamed it to : upstreamHost

location ~ /organizr-auth/(.*) {
    set              $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

and everything worked correctly. So renaming it from upstream to anything else - such as upstreamHost and setting your work around to remove the request_uri variable will fix this.

I edited /app/templates/_location.conf to this:

  location {{ path }} {
    set              $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

    {% if access_list_id > 0 %}
    {% if access_list.items.length > 0 %}
    # Authorization
    auth_basic            "Authorization required";
    auth_basic_user_file  /data/access/{{ access_list_id }};
 
    {{ access_list.passauth }}
    {% endif %}
 
    # Access Rules
    {% for client in access_list.clients %}
    {{- client.rule -}};
    {% endfor %}deny all;
 
    # Access checks must...
    {% if access_list.satisfy %}
    {{ access_list.satisfy }};
    {% endif %}
 
    {% endif %}

    {% include "_assets.conf" %}
    {% include "_exploits.conf" %}

    {% include "_forced_ssl.conf" %}
    {% include "_hsts.conf" %}

    {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %}
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    {% endif %}


    {{ advanced_config }}
  }

How would someone who uses/installs dockers via unRaid implement this solution? Are we able to edit the container as stated above as well?

@dirtymike0330 commented on GitHub (Nov 4, 2021): > @chaptergy I see exactly what the issue is now. We need to use a different variable name instead of `upstream` > > I renamed it to : `upstreamHost` > > ``` > location ~ /organizr-auth/(.*) { > set $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-Scheme $scheme; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass $upstreamHost; > ``` > > and everything worked correctly. So renaming it from `upstream` to anything else - such as `upstreamHost` and setting your work around to remove the `request_uri` variable will fix this. > > I edited `/app/templates/_location.conf` to this: > > ```nginx > location {{ path }} { > set $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-Scheme $scheme; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass $upstreamHost; > > {% if access_list_id > 0 %} > {% if access_list.items.length > 0 %} > # Authorization > auth_basic "Authorization required"; > auth_basic_user_file /data/access/{{ access_list_id }}; > > {{ access_list.passauth }} > {% endif %} > > # Access Rules > {% for client in access_list.clients %} > {{- client.rule -}}; > {% endfor %}deny all; > > # Access checks must... > {% if access_list.satisfy %} > {{ access_list.satisfy }}; > {% endif %} > > {% endif %} > > {% include "_assets.conf" %} > {% include "_exploits.conf" %} > > {% include "_forced_ssl.conf" %} > {% include "_hsts.conf" %} > > {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %} > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection $http_connection; > proxy_http_version 1.1; > {% endif %} > > > {{ advanced_config }} > } > ``` How would someone who uses/installs dockers via unRaid implement this solution? Are we able to edit the container as stated above as well?

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@KeysAU commented on GitHub (Nov 6, 2021):

Yep same issue, hope fix comes in unraid docker image soon!

@KeysAU commented on GitHub (Nov 6, 2021): Yep same issue, hope fix comes in unraid docker image soon!

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@PilaScat commented on GitHub (Nov 6, 2021):

@chaptergy I see exactly what the issue is now. We need to use a different variable name instead of upstream

I renamed it to : upstreamHost

location ~ /organizr-auth/(.*) {
    set              $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

and everything worked correctly. So renaming it from upstream to anything else - such as upstreamHost and setting your work around to remove the request_uri variable will fix this.

I edited /app/templates/_location.conf to this:

  location {{ path }} {
    set              $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %};
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $upstreamHost;

    {% if access_list_id > 0 %}
    {% if access_list.items.length > 0 %}
    # Authorization
    auth_basic            "Authorization required";
    auth_basic_user_file  /data/access/{{ access_list_id }};
 
    {{ access_list.passauth }}
    {% endif %}
 
    # Access Rules
    {% for client in access_list.clients %}
    {{- client.rule -}};
    {% endfor %}deny all;
 
    # Access checks must...
    {% if access_list.satisfy %}
    {{ access_list.satisfy }};
    {% endif %}
 
    {% endif %}

    {% include "_assets.conf" %}
    {% include "_exploits.conf" %}

    {% include "_forced_ssl.conf" %}
    {% include "_hsts.conf" %}

    {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %}
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    {% endif %}


    {{ advanced_config }}
  }

Tried this but nothing, I hope for a fix in the next updates

@PilaScat commented on GitHub (Nov 6, 2021): > @chaptergy I see exactly what the issue is now. We need to use a different variable name instead of `upstream` > > I renamed it to : `upstreamHost` > > ``` > location ~ /organizr-auth/(.*) { > set $upstreamHost http://10.124.0.4:8000/api/v2/auth/$1; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-Scheme $scheme; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass $upstreamHost; > ``` > > and everything worked correctly. So renaming it from `upstream` to anything else - such as `upstreamHost` and setting your work around to remove the `request_uri` variable will fix this. > > I edited `/app/templates/_location.conf` to this: > > ```nginx > location {{ path }} { > set $upstreamHost {{ forward_scheme }}://{{ forward_host }}:{{ forward_port }}{{ forward_path }}{% unless path contains "(" %}$request_uri{% endunless %}; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-Scheme $scheme; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass $upstreamHost; > > {% if access_list_id > 0 %} > {% if access_list.items.length > 0 %} > # Authorization > auth_basic "Authorization required"; > auth_basic_user_file /data/access/{{ access_list_id }}; > > {{ access_list.passauth }} > {% endif %} > > # Access Rules > {% for client in access_list.clients %} > {{- client.rule -}}; > {% endfor %}deny all; > > # Access checks must... > {% if access_list.satisfy %} > {{ access_list.satisfy }}; > {% endif %} > > {% endif %} > > {% include "_assets.conf" %} > {% include "_exploits.conf" %} > > {% include "_forced_ssl.conf" %} > {% include "_hsts.conf" %} > > {% if allow_websocket_upgrade == 1 or allow_websocket_upgrade == true %} > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection $http_connection; > proxy_http_version 1.1; > {% endif %} > > > {{ advanced_config }} > } > ``` Tried this but nothing, I hope for a fix in the next updates

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@casperse commented on GitHub (Nov 12, 2021):

Any news on this, seems to still be a problem

@casperse commented on GitHub (Nov 12, 2021): Any news on this, seems to still be a problem

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@dirtymike0330 commented on GitHub (Nov 12, 2021):

Any news on this, seems to still be a problem

They pushed out a new release and everything works fine for me now. Are you sure you're having the same problem as others on this thread?

@dirtymike0330 commented on GitHub (Nov 12, 2021): > Any news on this, seems to still be a problem They pushed out a new release and everything works fine for me now. Are you sure you're having the same problem as others on this thread?

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@casperse commented on GitHub (Nov 12, 2021):

I think so, I followed the IBRACORP guide to setup NPM with Organizr and it just stopped working after a update.
I have updated to the latest version but I still get this when trying to access the webpage through Organizr and the NMP setup:
{
"response": {
"result": "success",
"message": "User is authorized",
"data": {
"user": "MY-SUERNAME",
"group": 0,
"email": "MY-EMAIL",
"user_ip": "IP",
"requested_group": 0

(One thing I wdont know why its says group 0 the setup provides group 1)

@casperse commented on GitHub (Nov 12, 2021): I think so, I followed the IBRACORP guide to setup NPM with Organizr and it just stopped working after a update. I have updated to the latest version but I still get this when trying to access the webpage through Organizr and the NMP setup: { "response": { "result": "success", "message": "User is authorized", "data": { "user": "MY-SUERNAME", "group": 0, "email": "MY-EMAIL", "user_ip": "IP", "requested_group": 0 (One thing I wdont know why its says group 0 the setup provides group 1)

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 12, 2021):

make sure to make a change to the proxy so it re-saves. It needs to compile the conf file again.

@causefx commented on GitHub (Nov 12, 2021): make sure to make a change to the proxy so it re-saves. It needs to compile the conf file again.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@twitchstick commented on GitHub (Nov 16, 2021):

I'm still having an issue using this with unraid. I get the same message as casperse.

@twitchstick commented on GitHub (Nov 16, 2021): I'm still having an issue using this with unraid. I get the same message as casperse.

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@drkgatsby416 commented on GitHub (Nov 18, 2021):

i am also having this issues after following along with the docs here: https://docs.organizr.app/features/server-authentication/nginx-server-authentication

i just get the json payload saying user is authorized and i am using a fresh install of the latest version (2.9.12)

i looked at the _location.conf file and it isnt using the "$upstream" variable already, it uses "$targetUri" and has additional logic to what is displayed in previous posts here.

update: since somebody mentioned it was working in 2.9.9 i set the docker container to pull from that version and it is working. but would be nice to have a permanent fix to i can use latest :/

@drkgatsby416 commented on GitHub (Nov 18, 2021): i am also having this issues after following along with the docs here: https://docs.organizr.app/features/server-authentication/nginx-server-authentication i just get the json payload saying user is authorized and i am using a fresh install of the latest version (2.9.12) i looked at the _location.conf file and it isnt using the "$upstream" variable already, it uses "$targetUri" and has additional logic to what is displayed in previous posts here. update: since somebody mentioned it was working in 2.9.9 i set the docker container to pull from that version and it is working. but would be nice to have a permanent fix to i can use latest :/

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@causefx commented on GitHub (Nov 18, 2021):

I'm not sure if they have merged the reversal yet

@causefx commented on GitHub (Nov 18, 2021): I'm not sure if they have merged the reversal yet

kerem commented

2026-02-26 06:35:35 +03:00

Author

Owner

@muddro1 commented on GitHub (Dec 19, 2021):

This seems to be happening again with 2.9.12. Think this needs to be reopened.

@muddro1 commented on GitHub (Dec 19, 2021): This seems to be happening again with 2.9.12. Think this needs to be reopened.

Rows
Columns

[GH-ISSUE #1319] Auth_request module not behaving as expected with Organizr #1051