Login Loop, no reverse proxy or other additions.

[Jacksaur]

Organizr Version: V 2.1.2430

Branch: Master

WebServer: Nginx (Docker)

Operating System: Debian (Docker)

---

Problem Description:

I have a Raspberry pi bridging my LAN over a Zerotier VPN. It works for every site, except Organizr, which enters a Login loop. I can access the homepage on another device over the VPN, but entering my credentials just refreshes the login page. A success message appears at the bottom of the page, and in the Logs all my attempts are listed as: Authentication: User has logged in, with the IP address of my Pi listed.
I can access and login to each of my individual services, it's just Organizr that exhibits this login loop issue.

---

Reproduction Steps:

Access Organizr site over a VPN bridged device.
Enter login credentials.
Page will refresh, with notification of success, but nothing else.

---

[causefx]

anything else in logs after that? what about actual nginx logs?

[Jacksaur]

In actuality, doesn't seem like this was caused by my VPN connection after all.
I logged out on my desktop, tried to log in again in order to compare logs, and now it's exhibiting the same issue on my desktop with a direct connection over the LAN too. So now I lack access entirely.
I tried enabling some pages for the Guest group before doing so, and the login page just boots me to a Guest account instead of looping now.

My access.log file for nginx just seems log everything as sucessful, like the notification that appears:

192.168.0.6 - - [08/Oct/2023:16:10:09 +0000] "POST /api/v2/login HTTP/1.1" 200 113 "http://192.168.0.8/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"
192.168.0.6 - - [08/Oct/2023:16:10:09 +0000] "GET / HTTP/1.1" 200 5562 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"
192.168.0.6 - - [08/Oct/2023:16:10:09 +0000] "GET /api/v2/launch HTTP/1.1" 200 19700 "http://192.168.0.8/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"

There was nothing else in Organizr's logs section on the web client. The error.log and status_errors.log files are completely blank.
I'm expecting that I'm not providing the right log here, compared to other issues posted, but I couldn't find any paths on the docs on where to look.

I don't have a reverse proxy or anything fancy like that set up at all. Just a docker container in a composefile.

[causefx]

gotcha so you are accessing via ip:port?

can you check the permissions on the folder where the DB is stored? then check permissions on db and org logs files

[Jacksaur]

Yup, direct IP to my server on the same network as my PC. No port needed, as I left the container using port 80.

Checking through the folders, they're all owned by me, with R/W permissions.

[causefx]

can you chmod 777 the db just to test?Sent from my iPhoneOn Oct 8, 2023, at 12:39 PM, Jackson ***@***.***> wrote: Yup, direct IP to my server on the same network as my PC. No port needed, as I left the container using port 80. Checking through the folders, they're all owned by me, with R/W permissions. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[Jacksaur]

777'd the folder, no change.
Backed up the entire Organizr appdata folder and did the whole thing recursively, still nothing.

I spun up a new container and that appears to work fine.
Is there an exact path for my tabs I could copy over to the new container? I'd be fine with starting over if I could just import my tabs and categories back over.

[causefx]

copy the db over with the data/config/config.php

[Jacksaur]

Still causes the same issue.
Guess I'll have to settle for rebuilding my setup from scratch: And keeping backups this time!

Thank you for your help regardless.

[causefx]

there was nothing inside the error log in the nginx folder in the container?

[Jacksaur]

Nope, was the same as before. The error log files were entirely blank. I did check the older versions as well, and there was one random irrelevant error from weeks ago when things were still working which proved the logging was working, but nothing since then.