Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

403 Forbidden Error When Logging into Web Interface Despite Successful curl Command #85

Closed
Shasoosh opened this issue Nov 2, 2024 · 13 comments

Comments

@Shasoosh
Copy link

Shasoosh commented Nov 2, 2024

Hey,

Everything appears to be up and running, and the logs seem fine. When I run the following command:
curl -u 'admin:password' 'http://192.168.1.10:2875/manual?path=/Media/Videos/Movies/NameOfMovie/' it works and returns the appropriate response.

However, when I attempt to log in via the web interface at: http://192.168.1.10:2880/login
with the following credentials:

Server Url: https://192.168.1.10:2880/
u: admin
p: password
I receive a 403 Forbidden error.

Any ideas on what might be causing this issue?

Thanks.

My config file:

 app:
  log_level: trace

 opts:
   check_path: true # Check if the path exists, assuming the path is available to the container
   max_retries: 5 # Exponential backoff when a target fails

 triggers:
   manual:
     type: manual

 targets:
   plex:
     type: plex
     url: http://192.168.1.10:32400
     token: xxx

Logs:

2024-11-02T23:45:46.324062261+02:00  INFO autopulse: 💫 autopulse starting up...
2024-11-02T23:45:46.434237891+02:00  INFO autopulse::db::conn: Applied 4 migrations
2024-11-02T23:45:46.434323689+02:00  INFO autopulse: 🚀 Listening on 0.0.0.0:2875
PostgreSQL init process complete; ready for start up.
2024-11-02 21:45:44.512 UTC [1] LOG:  starting PostgreSQL 17.0 on x86_64-pc-linux-musl, compiled by gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309, 64-bit
2024-11-02 21:45:44.512 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-11-02 21:45:44.512 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2024-11-02 21:45:44.526 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-11-02 21:45:44.542 UTC [57] LOG:  database system was shut down at 2024-11-02 21:45:44 UTC
2024-11-02 21:45:44.554 UTC [1] LOG:  database system is ready to accept connections
@dan-online
Copy link
Owner

Hey @Shasoosh the "Server URL" needs to be the URL of the autopulse instance, which in your case is http://192.168.1.10:2875 where you instead put http://192.168.1.10:2880 which is the URL of the autopulseUI instance. Hope that fixes it!

@Shasoosh
Copy link
Author

Shasoosh commented Nov 3, 2024

Thanks, Dan. I tried that, but I'm still getting the same error. In fact, I get the same error no matter what server URL I enter.

Btw, I see the errors only if I inspect the page and open the console. There's no actual error messege like I get on autopulseui.pages.dev

@dan-online
Copy link
Owner

I see, could you share how you are running autopulse/autopulse-ui?

@Shasoosh
Copy link
Author

Shasoosh commented Nov 3, 2024

I use the same docker-compose to run everything. It's running on a synology nas.


services:
  autopulse:
    image: danonline/autopulse
    container_name: autopulse
    restart: always
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "2875:2875"
    networks:
      - db
    volumes:
      - /volume2/docker/autopulse/config.yaml:/app/config.yaml
      - /volume1/Media:/Media
      - /etc/localtime:/etc/localtime:ro # for correct timezone in timestamps
    environment:
      AUTOPULSE__APP__DATABASE_URL: postgres://autopulse:autopulse@postgres/autopulse

  # Optional self-hosted UI
  ui:
    image: danonline/autopulse:ui
    container_name: autopulse-ui
    restart: always
    ports:
      - "2880:2880"
    networks:
      - db
    #environment:
      #SECRET: my-secret # Optional to prevent being logged out when the container restarts


  postgres:
    image: postgres:alpine
    container_name: autopulse-postgres
    restart: always
    networks:
      - db
    environment:
      POSTGRES_USER: autopulse
      POSTGRES_PASSWORD: autopulse
      POSTGRES_DB: autopulse
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - /volume2/docker/autopulse/db:/var/lib/postgresql/data

networks:
  db:
    driver: bridge

@dan-online
Copy link
Owner

dan-online commented Nov 3, 2024

Ah I see the issue, so the request to the instance doesn't happen in the browser, it happens in the UI container. Since the UI container doesn't have access to http://192.168.1.10:2875, it's probably erroring. I don't know why that's a 403 so I may have to investigate more there.

However the solution should be if you provide http://autopulse:2875 as the Server URL. This should work as both the UI and the instance are on the same network db

You could also set the UI to be network_mode: host I believe if you would prefer it to access through the autopulse published port

@Shasoosh
Copy link
Author

Shasoosh commented Nov 3, 2024

Thanks.

Trying to access http://autopulse:2875 as the server url will also result in 403.

I've also tried changing the docker-compose to:

ui:
    image: danonline/autopulse:ui
    container_name: autopulse-ui
    restart: always
    ports:
      - "2880:2880"
    network_mode: host

but that also gave me 403.

Any other suggestions?

It would be very helpful if additional logs could be integrated into the UI, as currently, there isn't much information to work with.

Edit: If I go to the container console and run:
/app # curl -I http://autopulse:2875

I'm getting
HTTP/1.1 404 Not Found
content-length: 0
date: Sun, 03 Nov 2024 16:37:37 GMT

Which means that it is reachable, but for some reason it's not reacble from the UI.

@dan-online
Copy link
Owner

Hmm, that's odd mainly because curling the root path should return a json object like so:

{"autopulse":"v1.1.0"}

@Shasoosh
Copy link
Author

Shasoosh commented Nov 3, 2024

I can access the JSON response directly by visiting http://192.168.1.10:2875 in a browser. This suggests there's an issue with the communication between the containers. Strange.

@myhme myhme mentioned this issue Nov 4, 2024
@dan-online
Copy link
Owner

dan-online commented Nov 4, 2024

I think it's a 404 since you used -I and autopulse doesn't support HEAD requests hence the not found, so that at least explains that.

As for the 403, I don't send a 403 anywhere, only Unauthorized which is a 401. Therefore I pushed 0656aaf which will log all requests in both frontend/backend, so perhaps try with that and see what comes up?

@Shasoosh
Copy link
Author

Shasoosh commented Nov 4, 2024

Thanks Dan. You are right regarding the -I - removing it will return the json.
I've updated my containers and attempted to sign in, but this is the result:

image

The UI logs however will show me this:

Generated new secret: 033d59c6-...
Listening on 0.0.0.0:2880
2024-11-04T10:39:46.748Z [GET] - 302 https://192.168.1.10:2880/ - 7.289ms
2024-11-04T10:39:46.775Z [GET] - 200 https://192.168.1.10:2880/login - 17.067ms

The [GET] lines are logged when I access the UI through the browser. However, after clicking the Sign in button, no new log lines are generated.

@tam1m
Copy link

tam1m commented Nov 4, 2024

The issue is described here sveltejs/kit#6589

I can reproduce this when accessing the ui via ip (http://10.66.66.1:2880) connecting to autopulse at http://10.66.66.1:2875.

Adding the ORIGIN envar to the ui fixes this. I guess this is not a problem in production but when hosting locally and accessing it via ip as indicated by the 403 response Cross-site POST form submissions are forbidden

  autopulse-ui:
    image: danonline/autopulse:ui
    container_name: autopulse-ui
    restart: always
    ports:
      - 127.0.0.1:2880:2880
      - 10.66.66.1:2880:2880
    environment:
      SECRET: ************
      ORIGIN: http://10.66.66.1:2880
    networks:
      - shitflix_net

Svelte Docs: https://svelte.dev/docs/kit/adapter-node#Environment-variables-ORIGIN-PROTOCOL_HEADER-HOST_HEADER-and-PORT_HEADER

@Shasoosh
Copy link
Author

Shasoosh commented Nov 4, 2024

Thanks @tam1m, you nailed it!
Adding ORIGIN to docker-compose fixes the issue.

@dan-online
Copy link
Owner

Ah interesting, cheers @tam1m, I'll add this in the docker-compose example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants