stoatchat/self-hosted
1
0
Fork 0
mirror of https://github.com/stoatchat/self-hosted.git synced 2026-07-21 04:25:24 -04:00
Code Issues 42 Packages Projects Releases Wiki Activity

Account created but login fails #131

New Issue
Open
opened 2026-02-16 12:51:35 -05:00 by yindo · 9 comments
yindo commented 2026-02-16 12:51:35 -05:00
Owner
Copy Link
Copy Source

Originally created by @noisymuffin on GitHub (Feb 11, 2026).

Got the server running by following the instructions on the main page. Running Ubuntu 24.04.3 LTS, fully updated.

I've:

  • Created a user
  • Received the verification email and verified
  • But now when I try to log in I get this error.
    Image

On the server, observing the logs usingdocker compose logs -f:

api-1            |  INFO  rocket::server                                                   > POST /auth/session/login application/json:
api-1            |  INFO  rocket::server::_                                                > Matched: (login) POST /auth/session/login
api-1            |  INFO  rocket::server::_                                                > Outcome: Success(200 OK)
api-1            |  INFO  rocket::server::_                                                > Response succeeded.
api-1            |  INFO  rocket::server                                                   > GET /onboard/hello application/json:
api-1            |  INFO  rocket::server::_                                                > Matched: (hello) GET /onboard/hello
api-1            |  INFO  rocket::server::_                                                > Outcome: Success(200 OK)
api-1            |  INFO  rocket::server::_                                                > Response succeeded.
api-1            |  INFO  rocket::server                                                   > GET /onboard/hello application/json:
api-1            |  INFO  rocket::server::_                                                > Matched: (hello) GET /onboard/hello
api-1            |  INFO  rocket::server::_                                                > Outcome: Success(200 OK)
api-1            |  INFO  rocket::server::_                                                > Response succeeded.
database-1       | {"t":{"$date":"2026-02-12T00:47:30.461+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:56038","connectionId":68,"connectionCount":17}}
database-1       | {"t":{"$date":"2026-02-12T00:47:30.464+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn68","msg":"client metadata","attr":{"remote":"127.0.0.1:56038","client":"conn68","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.30"},"os":{"type":"Linux","name":"Ubuntu","architecture":"x86_64","version":"20.04"}}}}
database-1       | {"t":{"$date":"2026-02-12T00:47:30.489+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn68","msg":"Connection ended","attr":{"remote":"127.0.0.1:56038","connectionId":68,"connectionCount":16}}

Had to change the healthcheck for the database service so that it succeeds:
test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet

Also had a problem with redis always restarting, changed docker tags to an older version and it seems stable now:

  redis:
    image: docker.io/eqalpha/keydb:x86_64_v6.3.3
    restart: always

I run my own caddy server on a separate server, which just forwards to stoat's caddy server on port 1234:

  caddy:
    image: docker.io/caddy
    restart: always
    env_file: .env.web
    ports:
      - "1234:80"
#      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - /chat/stoat/caddy-data:/data
      - /chat/stoat/caddy-config:/config

I've got all host URLs set to cleartext in Revolt.toml:

[hosts]
app = "http://stoat.mydomain.com"
api = "http://stoat.mydomain.com/api"
events = "ws://stoat.mydomain.com/ws"
autumn = "http://stoat.mydomain.com/autumn"
january = "http://stoat.mydomain.com/january"

My .env.web:

HOSTNAME=:80
REVOLT_PUBLIC_URL=http://stoat.mydomain.com/api
Originally created by @noisymuffin on GitHub (Feb 11, 2026). Got the server running by following the instructions on the main page. Running Ubuntu 24.04.3 LTS, fully updated. I've: - Created a user - Received the verification email and verified - But now when I try to log in I get this error. <img width="445" height="196" alt="Image" src="https://github.com/user-attachments/assets/fd3d5f0a-6c50-4395-bb56-75d9584412ca" /> On the server, observing the logs using`docker compose logs -f`: ``` api-1 | INFO rocket::server > POST /auth/session/login application/json: api-1 | INFO rocket::server::_ > Matched: (login) POST /auth/session/login api-1 | INFO rocket::server::_ > Outcome: Success(200 OK) api-1 | INFO rocket::server::_ > Response succeeded. api-1 | INFO rocket::server > GET /onboard/hello application/json: api-1 | INFO rocket::server::_ > Matched: (hello) GET /onboard/hello api-1 | INFO rocket::server::_ > Outcome: Success(200 OK) api-1 | INFO rocket::server::_ > Response succeeded. api-1 | INFO rocket::server > GET /onboard/hello application/json: api-1 | INFO rocket::server::_ > Matched: (hello) GET /onboard/hello api-1 | INFO rocket::server::_ > Outcome: Success(200 OK) api-1 | INFO rocket::server::_ > Response succeeded. database-1 | {"t":{"$date":"2026-02-12T00:47:30.461+00:00"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:56038","connectionId":68,"connectionCount":17}} database-1 | {"t":{"$date":"2026-02-12T00:47:30.464+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn68","msg":"client metadata","attr":{"remote":"127.0.0.1:56038","client":"conn68","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.30"},"os":{"type":"Linux","name":"Ubuntu","architecture":"x86_64","version":"20.04"}}}} database-1 | {"t":{"$date":"2026-02-12T00:47:30.489+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn68","msg":"Connection ended","attr":{"remote":"127.0.0.1:56038","connectionId":68,"connectionCount":16}} ``` Had to change the healthcheck for the database service so that it succeeds: `test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet` Also had a problem with redis always restarting, changed docker tags to an older version and it seems stable now: ``` redis: image: docker.io/eqalpha/keydb:x86_64_v6.3.3 restart: always ``` I run my own caddy server on a separate server, which just forwards to stoat's caddy server on port 1234: ``` caddy: image: docker.io/caddy restart: always env_file: .env.web ports: - "1234:80" # - "443:443" volumes: - ./Caddyfile:/etc/caddy/Caddyfile - /chat/stoat/caddy-data:/data - /chat/stoat/caddy-config:/config ``` I've got all host URLs set to cleartext in Revolt.toml: ``` [hosts] app = "http://stoat.mydomain.com" api = "http://stoat.mydomain.com/api" events = "ws://stoat.mydomain.com/ws" autumn = "http://stoat.mydomain.com/autumn" january = "http://stoat.mydomain.com/january" ``` My .env.web: ``` HOSTNAME=:80 REVOLT_PUBLIC_URL=http://stoat.mydomain.com/api ```
yindo commented 2026-02-16 12:51:35 -05:00
Author
Owner
Copy Link
Copy Source

@JimmyBassy commented on GitHub (Feb 11, 2026):

I was able to solve this with nginx by having a separate config for web sockets, here's my config:
location /ws { proxy_pass http://127.0.0.1:8008; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; }

These are mainly needed headers for websockets to work behind a reverse proxy.

Sorry but I'm unable to format it correctly

@JimmyBassy commented on GitHub (Feb 11, 2026): I was able to solve this with nginx by having a separate config for web sockets, here's my config: ` location /ws { proxy_pass http://127.0.0.1:8008; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; } ` These are mainly needed headers for websockets to work behind a reverse proxy. Sorry but I'm unable to format it correctly
yindo commented 2026-02-16 12:51:35 -05:00
Author
Owner
Copy Link
Copy Source

@kiwidoggie commented on GitHub (Feb 12, 2026):

https://nginx.org/en/docs/http/websocket.html

Reference.

@kiwidoggie commented on GitHub (Feb 12, 2026): https://nginx.org/en/docs/http/websocket.html Reference.
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@seva-luchianov commented on GitHub (Feb 12, 2026):

Looks like I have the same issue
https://github.com/stoatchat/self-hosted/issues/162#issuecomment-3887148863

server {
        server_name my.domain.tld;
        location / {
                proxy_pass http://127.0.0.1:1234;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $host;
        }

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        client_max_body_size 20M;

    listen 443 ssl; # managed by Certbot
    # omitted certbot stuff
}

Not sure why my version does not work - will try moving the ws nginx conf into its own location section.

@seva-luchianov commented on GitHub (Feb 12, 2026): Looks like I have the same issue https://github.com/stoatchat/self-hosted/issues/162#issuecomment-3887148863 ``` server { server_name my.domain.tld; location / { proxy_pass http://127.0.0.1:1234; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; } proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 20M; listen 443 ssl; # managed by Certbot # omitted certbot stuff } ``` Not sure why my version does not work - will try moving the ws nginx conf into its own location section.
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@seva-luchianov commented on GitHub (Feb 12, 2026):

Now I get a different error

database-1       | {"t":{"$date":"2026-02-12T18:12:53.811+00:00"},"s":"I",  "c":"ACCESS",   "id":10483900,"ctx":"conn28","msg":"Connection not authenticating","attr":{"client":"127.0.0.1:41016","doc":{"application":{"name":"mongosh 2.6.0"},"driver":{"name":"nodejs|mongosh","version":"6.19.0|2.6.0"},"platform":"Node.js v20.20.0, LE","os":{"name":"linux","architecture":"x64","version":"3.10.0-327.22.2.el7.x86_64","type":"Linux"},"env":{"container":{"runtime":"docker"}}}}}

@noisymuffin is this what you were seeing that led you to tweak the db health check?

What's weird is that I'm able to register users, so presumably the db IS working?

@seva-luchianov commented on GitHub (Feb 12, 2026): Now I get a different error ``` database-1 | {"t":{"$date":"2026-02-12T18:12:53.811+00:00"},"s":"I", "c":"ACCESS", "id":10483900,"ctx":"conn28","msg":"Connection not authenticating","attr":{"client":"127.0.0.1:41016","doc":{"application":{"name":"mongosh 2.6.0"},"driver":{"name":"nodejs|mongosh","version":"6.19.0|2.6.0"},"platform":"Node.js v20.20.0, LE","os":{"name":"linux","architecture":"x64","version":"3.10.0-327.22.2.el7.x86_64","type":"Linux"},"env":{"container":{"runtime":"docker"}}}}} ``` @noisymuffin is this what you were seeing that led you to tweak the db health check? What's weird is that I'm able to register users, so presumably the db IS working?
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@gr33k commented on GitHub (Feb 12, 2026):

I've been toying with this and Nginx as a reverse proxy (I have multiple services on this server)....it just isn't wanting to work right yet. I'm sure it's a problem with the ports and reverse proxy (notably websockets)- but I wish this project was more streamlined to work with a nginx reverse proxy (it's super popular)...or perhaps add that in the compose file ready to go + nginx example you could easily copy and paste in to your nginx setup. No port allocations are present either in the event you want to expose/change them. Yes you can add all this stuff, but the goal would be to simplify this for the wave of people looking to replace Discord with something like this ;)

@gr33k commented on GitHub (Feb 12, 2026): I've been toying with this and Nginx as a reverse proxy (I have multiple services on this server)....it just isn't wanting to work right yet. I'm sure it's a problem with the ports and reverse proxy (notably websockets)- but I wish this project was more streamlined to work with a nginx reverse proxy (it's super popular)...or perhaps add that in the compose file ready to go + nginx example you could easily copy and paste in to your nginx setup. No port allocations are present either in the event you want to expose/change them. Yes you can add all this stuff, but the goal would be to simplify this for the wave of people looking to replace Discord with something like this ;)
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@noisymuffin commented on GitHub (Feb 12, 2026):

@noisymuffin is this what you were seeing that led you to tweak the db health check?

No, I'm running on an older system so I have to use MongoDB v4.4. For me, the database was starting in an unhealthy state so the other services were failing. The mongosh command didn't exist on v4.4 - thus my change to the healthcheck command.

@noisymuffin commented on GitHub (Feb 12, 2026): > [@noisymuffin](https://github.com/noisymuffin) is this what you were seeing that led you to tweak the db health check? No, I'm running on an older system so I have to use MongoDB v4.4. For me, the database was starting in an unhealthy state so the other services were failing. The mongosh command didn't exist on v4.4 - thus my change to the healthcheck command.
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@seva-luchianov commented on GitHub (Feb 12, 2026):

Huh, thanks for letting me know! Seems like I'm the only person on the internet seeing Connection not authenticating in the db logs with zero tweaks to default configs 😅
Let's see if my separate issue gets any traction.

@seva-luchianov commented on GitHub (Feb 12, 2026): Huh, thanks for letting me know! Seems like I'm the only person on the internet seeing `Connection not authenticating` in the db logs with zero tweaks to default configs 😅 Let's see if my separate issue gets any traction.
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@gr33k commented on GitHub (Feb 12, 2026):

Funny enough - setting up a brand new VM running Ubuntu 24 server ... I simply had to change the .env.web HOSTNAME=:80 as mentioned for reverse proxy support...Using Nginx Proxy Manager (docker on another server) - I pointed to the http://LANIP:80 with websocket support enabled. I was able to enable HTTPS w/ letsencrypt and it's working fine.

Not sure why this struggles to work on my Ubuntu 18 VPS or my physical Fedora 40 server...but alas - If you want to avoid a big headache - set this up on a fresh Ubuntu 24 and you can have it working in a few minutes vs a few hours I wasted trying to get it working elsewhere 😆

@gr33k commented on GitHub (Feb 12, 2026): Funny enough - setting up a brand new VM running Ubuntu 24 server ... I simply had to change the .env.web HOSTNAME=:80 as mentioned for reverse proxy support...Using Nginx Proxy Manager (docker on another server) - I pointed to the http://LANIP:80 with websocket support enabled. I was able to enable HTTPS w/ letsencrypt and it's working fine. Not sure why this struggles to work on my Ubuntu 18 VPS or my physical Fedora 40 server...but alas - If you want to avoid a big headache - set this up on a fresh Ubuntu 24 and you can have it working in a few minutes vs a few hours I wasted trying to get it working elsewhere 😆
yindo commented 2026-02-16 12:51:36 -05:00
Author
Owner
Copy Link
Copy Source

@noisymuffin commented on GitHub (Feb 13, 2026):

Thats the thing, mine is a fresh Ubuntu 24 install dedicated just for Stoat. Other than setting up hosting on a VPS I've followed all instructions on the main page, fixed the issues with mongodb and keydb docker tags, and then the reverse proxy instructions.
Its rather frustrating how unhelpful the logs are despite the error.
Perhaps it is websockets related, but from my understanding of Caddy it handles most of these things automatically. I'll keep digging.

For reference, here is my caddy configuration on my other server:

stoat.mydomain.com {
  tls /data/caddy/certs/mydomain.com/fullchain.pem /data/caddy/certs/mydomain.com/privkey.pem
  reverse_proxy /ws/* http://192.168.5.3:1234
}
@noisymuffin commented on GitHub (Feb 13, 2026): Thats the thing, mine is a fresh Ubuntu 24 install dedicated just for Stoat. Other than setting up hosting on a VPS I've followed all instructions on the main page, fixed the issues with mongodb and keydb docker tags, and then the reverse proxy instructions. Its rather frustrating how unhelpful the logs are despite the error. Perhaps it is websockets related, but from my understanding of Caddy it handles most of these things automatically. I'll keep digging. For reference, here is my caddy configuration on my other server: ``` stoat.mydomain.com { tls /data/caddy/certs/mydomain.com/fullchain.pem /data/caddy/certs/mydomain.com/privkey.pem reverse_proxy /ws/* http://192.168.5.3:1234 } ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
good first issue
help wanted
improvement
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: stoatchat/self-hosted#131
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?