Server error behind reverse proxy

Question

Server error behind reverse proxy

Opened this issue 2 years ago · 11 comments

rlsvr commented 2 years ago

"Server Error - Something went wrong" when accessing from the web. Local works fine.

Answer 1 · 2022-11-14T21:05:48.000Z

Hey @rlsvr
Make sure you've updated API_BASE_URL accordingly as suggested here:
#2 (comment)

Answer 2 · 2022-11-15T18:41:36.000Z

Hello, yes, it only solves the issue when you try it access it locally

Answer 3 · 2022-11-15T20:24:32.000Z

Ok, I need some additional information, because it is hard to tell where is the problem. The console errors would be useful as well as logs from shelf-back container.

Let's start with simple one - does request hit the server at all?

Answer 4 · 2022-11-19T00:34:01.000Z

There is no log generated on the backend side.
There could be an issue I moved to 8002 and 8082?

Answer 5 · 2022-11-19T08:30:36.000Z

if you don't see any errors on the backend side, it means the request even don't hit the backend. So we need to take a look on what's happening on the front-end. The console error log or screenshot would be useful. Check that requests are sent to the correct backend URL

It is totally OK to change ports, just make sure you update API_BASE_URL in the docker-compose.yml and CORS_ALLOW_ORIGINS.

Answer 6 · 2022-11-22T15:46:49.000Z

Sometimes it works, but usually

"api.js:73 Mixed Content: The page at 'https://..../signin?next=/' was loaded over HTTPS, but requested an insecure resource 'http://10.5.4.202:8002/auth/sign_in'. This request has been blocked; the content must be served over HTTPS.
Lz @ api.js:73"

so problem is with TLS

Answer 7 · 2022-11-23T12:51:59.000Z

I guess the problem somewhere in the reverse proxy configuration, not with the project itself. The frontend is loaded via https and requests to the backend are sent via http. The protocol should be the same, either load everything with http or with https.

Answer 8 · 2022-12-01T12:40:44.000Z

Hi!

I have the same problem.

The instance is running behind a reverse proxy on https://shelf.mysite.com/
on the the signup page it tries to contact http://localhost:8050/auth/sign_up and hence throws a CORS error. (And it wouldn't reach localhost anyway.)

Answer 9 · 2022-12-05T09:48:24.000Z

Hey, @sommerper

Your are right, the backend (shelf-back) should also be available on the internet.

What is the value of the API_BASE_URL environment variable in the docker-compose.yml?

From my point of view your setup should look something like this:

the frontend running behind reverse proxy on https://shelf.mysite.com
the backend also running behind reverse proxy on https://api-shelf.mysite.com
the API_BASE_URL is set to https://api-shelf.mysite.com

Answer 10 · 2023-03-16T22:58:00.000Z

Hmm.. I see... But is that really necessary to expose the back-end to the web?

Obviously I'm not sure about the inner workings of Shelf but shouldn't dockers networks be use to ensure the containers are running on the same internal network?

Answer 11 · 2023-04-07T23:53:16.000Z

@sommerper

Shelf is a Single Page Application and the way it works is frontend, which is a typically some JavaScript application, runs in your browser and communicates with a backend API (Application Programming Interface) running on a server.

The frontend served by shelf-front container in the docker-compose. What it essentially does is just sending to your browser a bunch of files once on the initial page load and then browser runs it.

The backend is served by shelf-back container in the docker-compose. It stores user files, communicates with storage and so on.

In that scheme shelf-front and shelf-back never communicate with each other. It is the browser that sends requests to the server. The server is served by shelf-back container and browser knows nothing about docker network, so it has to exposed in some way.

Hope that makes sense!