[Feature request] Ability to serve Single Page Applications from static server #213

New issue

Open

opened 2023-07-22 18:57:44 +02:00 by roquie · 3 comments

roquie commented

2023-07-22 18:57:44 +02:00

(Migrated from github.com)

Is your feature request related to a problem? Please describe.
I would like use frontend router based on history API and static webserver can be to have special mode for it. Right now redirect to login_url (eg. login_url="auth/login") can't possible because server can't find html file.

Describe the solution you'd like
Solution 1: link - serve files like this
Solution 2: An ability to separate webapp application and backend to deploy it independently (right now I can't set different URI for redirect to my webapp service).

**Is your feature request related to a problem? Please describe.** I would like use [frontend router](https://v5.reactrouter.com/web/guides/quick-start) based on history API and static webserver can be to have special mode for it. Right now redirect to `login_url` (eg. `login_url="auth/login"`) can't possible because server can't find html file. **Describe the solution you'd like** Solution 1: [link](https://stackoverflow.com/a/43954597) - serve files like this Solution 2: An ability to separate webapp application and backend to deploy it independently (right now I can't set different URI for redirect to my webapp service).

babelouest commented

2023-07-24 13:48:14 +02:00

(Migrated from github.com)

Hello,

I'm not sure this feature would be possible as-is, because the config parameter login_url is meant to be used for HTTP 302 redirections when the oidc plugin requires an authentication.
The redirection is built using the config parameter external_url, the login_url and additional parameters such as client_id, state, redirect_uri, etc.

If you want to use a frontend router in the login page, you can modify its code to serve your goals though.

Hello, I'm not sure this feature would be possible as-is, because the config parameter `login_url` is meant to be used for HTTP 302 redirections when the oidc plugin requires an authentication. The redirection is built using the config parameter `external_url`, the `login_url` and additional parameters such as `client_id`, `state`, `redirect_uri`, etc. If you want to use a frontend router in the login page, you can modify its [code](https://github.com/babelouest/glewlwyd/tree/master/webapp-src) to serve your goals though.

roquie commented

2023-07-24 19:15:29 +02:00

(Migrated from github.com)

We can built redirection only with login_url if it contains absolute url?

P.S. I can't use built-in webapp-src because I already has my react frontend with some pages / components already completed. I want to re-implement some logic used in webapp-src in my react app.

P.P.S. We can verify base domain for that.

We can built redirection only with `login_url` if it contains absolute url? P.S. I can't use built-in webapp-src because I already has my react frontend with some pages / components already completed. I want to re-implement some logic used in webapp-src in my react app. P.P.S. We can verify base domain for that.

roquie commented

2023-07-25 07:30:40 +02:00

(Migrated from github.com)

I apologize, maybe I didn't convey my point well.

My question is actually directly related to the division of the service into 2 parts: frontend and backend. Right now, without some tricks like a proxy server or react hash router, I can't separate the server and the frontend (I mean, I managed to solve this issue, but through a workaround).

You have the option to turn off the static server, but you still have to specify the login_url in the settings and it will still redirect to it. As if there is no binding of the server to the frontend, but it still remains through binding to the reverse proxy, through which you have to route.

I propose to think of any safe way to separate API and frontend without using crutches like reverse-proxy or react hash router. That is, to allocate the frontend entirely to a separate web server (in my case it's aws s3), which delivers statics and does nothing else.

P.S. When I use my frontend instead of the built-in one, which is a bit heavier (due to images and svg), for some reason the server is visually noticeably slower to load them than the usual nginx.... Just an observation (UPD: it's a cache headers).

I apologize, maybe I didn't convey my point well. My question is actually directly related to the division of the service into 2 parts: frontend and backend. Right now, without some tricks like a proxy server or react hash router, I can't separate the server and the frontend (I mean, I managed to solve this issue, but through a workaround). You have the option to turn off the static server, but you still have to specify the login_url in the settings and it will still redirect to it. As if there is no binding of the server to the frontend, but it still remains through binding to the reverse proxy, through which you have to route. I propose to think of any safe way to separate API and frontend without using crutches like reverse-proxy or react hash router. That is, to allocate the frontend entirely to a separate web server (in my case it's aws s3), which delivers statics and does nothing else. P.S. When I use my frontend instead of the built-in one, which is a bit heavier (due to images and svg), for some reason the server is visually noticeably slower to load them than the usual nginx.... Just an observation (**UPD**: it's a cache headers).

This discussion has been locked. Commenting is limited to contributors.