search

C9Glax / tranga

Docker-Container to monitor (Manga) Scanlation-Sites for download new chapters.
GNU General Public License v3.0
157 stars 15 forks source link

API connection rejected #55

Closed mattephi closed 1 year ago

mattephi commented 1 year ago

Maybe related to #4

Console spits the following:

Not allowed to request resource
Fetch API cannot load http://website:6531/Tasks/RunningTasks due to access control checks.

And so on for each of the files

Tranga is deployed on linux vps and being accessed through caddy reverse proxy. Caddy automatically certifies all the domains, so connection is through https

C9Glax commented 1 year ago

Hey!

Definitely related, and probably a CORS check that fails. Will look into that further when #41 is released.

C9Glax commented 1 year ago

Just a quick thought: You are running the website though a https-connection? Then you won't be able to access any http-connections. If you can, try and reverse-proxy tranga-api as well with a ssl-cert.

C9Glax commented 1 year ago

Okay since there hasn't been a reply in over a month, I will be closing this. Right now reverse-proxying and certificates are too much for me to figure out. I would recommend only running this locally in the network anyways.

mattephi commented 11 months ago

Sorry for long response, I gave up on this for a while. However I tried today again, and managed to get it up and running. I use caddy for proxying and steps to reproduce my workaround are as follows:

  1. get everything running with compose
  2. reverse proxy both api and website with caddy
  3. modify the apiConnector.js in website container 3.1. point apiUri to https endpoint 3.2. remove cookies code associated with apiUri (somehow they are managed improperly and website tries to access local files instead)

Api requests are handled, so I suppose everything is working properly.

Do you actually need cookies for storing api uri information? I think proper solution would be, for example, env variable with fallback to default url. It will add flexibility with api without a lot of additional hassle, I think

C9Glax commented 11 months ago

Do you actually need cookies for storing api uri information? I think proper solution would be, for example, env variable with fallback to default url. It will add flexibility with api without a lot of additional hassle, I think

Yes, the whole website is client-sided and if you want information to persist a cookie is the easiest way. You don't need to modify the apiUri in the container, you can just update it on the website in the settings.

mattephi commented 11 months ago

Cookies in general of course seem legitimate, but why they should contain api uri? Very unlikely each device connecting to site will need different api, while very likely each device will need same api url (probably non-default). Modifying the api url client side inconvenient in my case, where I access the same site with same api (nonstandard) from different devices.

Do you actually need cookies for storing api uri information? I think proper solution would be, for example, env variable with fallback to default url. It will add flexibility with api without a lot of additional hassle, I think

Yes, the whole website is client-sided and if you want information to persist a cookie is the easiest way. You don't need to modify the apiUri in the container, you can just update it on the website in the settings.

C9Glax commented 11 months ago

True it's redundant, I will figure out a way to just have it as ENV-var at some point