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

[Feature Request] Web path prefix support #139

Closed
sgpublic opened this issue Aug 6, 2024 · 7 comments
Closed

[Feature Request] Web path prefix support #139

sgpublic opened this issue Aug 6, 2024 · 7 comments

Comments

@sgpublic
Copy link

sgpublic commented Aug 6, 2024

As the title says, if web prefixes are supported, multiple instances can be deployed on a single domain name without conflicts.

There is already a PR: #42, but it is too old to be merged into the current repository.

Is there any plan to support this feature or accept PR? Thank you!

@jlesage
Copy link
Owner

jlesage commented Aug 6, 2024

Could you provide more details about the use case ? If you are running multiple instances, I guess they each run on different ports ? So you need to run them behind a reverse proxy or something like that ?

@sgpublic
Copy link
Author

sgpublic commented Aug 6, 2024

Yes, I need to run noVNC behind a reverse proxy.

Specifically, I built my own image using docker-baseimage-gui, and then used noVNC and Web authentication (WEB_AUTHENTICATION ). Since I need to deploy multiple instances at the same time and also need public HTTPS access, I hope to access different instances through paths with different prefixes of a single domain name.

For example:

Currently, if I enable WEB_AUTHENTICATION, it will be forced to jump to /login/ when accessing. I have tried the following configuration:

    location ~ /container/instance1 {
        include /etc/nginx/common.d/listen_location.conf;
        rewrite ^/container/instance1$ / break;
        rewrite ^/container/instance1(.*)$ $1 break;
        proxy_redirect https://$server_name/ /container/instance1/;
        proxy_pass https://$NAS_IP:5800;
    }

But the login interface on the web page uses /login/login: /rootfs/opt/noVNC/login/index.html#L35, external configuration alone can no longer meet this requirement.

@jlesage
Copy link
Owner

jlesage commented Aug 6, 2024

Ok, so yes, the way to go is to use the reverse proxy to server the interface of a container under a different path. You can check one of my container's documentation for an example of proxy configuration (e.g. https://github.com/jlesage/docker-crashplan-pro?tab=readme-ov-file#routing-based-on-url-path).

The bug/problem, as you mentioned, is the login page that uses absolute path. This can be fixed.

Is it working well without WEB_AUTHENTICATION enabled ?

@sgpublic
Copy link
Author

sgpublic commented Aug 6, 2024

Is it working well without WEB_AUTHENTICATION enabled ?

Yes, it works well after I modified the configuration:

    location = /container/instance1 {
        return 302 https://$server_name/container/instance1/;
    }
    location ~ /container/instance1/ {
        include /etc/nginx/common.d/listen_location.conf;
        rewrite ^/container/instance1(.*)$ $1 break;
        proxy_redirect https://$server_name/ /container/instance1/;
        proxy_pass https://$NAS_IP:5800;
    }

The bug/problem, as you mentioned, is the login page that uses absolute path. This can be fixed.

I modified /rootfs/opt/noVNC/login/index.htm locally:

                     <div id="loginStatus" class="alert alert-danger mb-4 d-none" role="alert">
                     </div>
-                    <form action="/login/login" method="post" id="loginForm" novalidate>
+                    <form action="login" method="post" id="loginForm" novalidate>
                     <div class="form-floating mb-3">

Now it works fine when WEB_AUTHENTICATION is enabled.

@jlesage
Copy link
Owner

jlesage commented Aug 7, 2024

I found few other things that doesn't work well (fonts, logout, etc). I'm working on fixing these.

@sgpublic
Copy link
Author

I found few other things that doesn't work well (fonts, logout, etc). I'm working on fixing these.

Hey, just checking in—any idea when we might get the next release? 😊

@jlesage
Copy link
Owner

jlesage commented Aug 31, 2024

Fixed in version 4.6.4.

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

2 participants