We intend to drop official support for Rocket.Chat installation under subdirectories (with Release 4.0).
Over the years there have been many times that we’ve added a new piece of functionality or a contribution merged and it’s ended up with subdirectory support broken. Subdirectory support is complicated in general. But for a large and complex code base like ours we don’t feel maintaining support for it is doing either of us favors.
I think the support for installation in subdirectory is important because sometimes I use Rocket.Chat by IP without domain.I’m installing Rocket.Chat in subdirectory now.
What you are describing is running out of folder on your computer. That will not go away. That is to do with installation. We are talking about how it is accessed.
You may misunderstand.I mean I don’t have domain and access RocketChat by http://xxx.xxx.xxx.xxx/chat (xxx.xxx.xxx.xxx is my server ip) and http://xxx.xxx.xxx.xxx/ has other server,so it’s important to support installation in subdirectory.(My English is poor,sorry)
Okay. Thank you very much for your answers and input.
This is very atypical. I have not heard of another case of users who did not need the mobile apps and do not care about privacy of their connection over the Internet for their deployment.
At the time when all communications tend to be HTTPS which implies an IP for each host and an SSL certificate for each host, not being able to install their excellent Rocket.Chat program in a subdirectory, I consider it to be a regression.
In our particular case we have installed your program in a subdirectory. But additionally on the same hosts we have the company website, the support ticket manager, the opensource Etherpad program, the opensource NextCloud program, mail server, webmail server, LDAP server, etc …
I consider that it would be a regression and would imply additional costs not being able to install the Rocket.Chat in a subdirectory (IP + SSL certificate).
Thanks in advance for your excellent opensource program.
Is there some reason why you might not be taking advantage of the free certs available via Lets Encrypt https://letsencrypt.org/? This alternative should be widely supported by almost all hosting providers.
A subdirectory installation is more comfortable for us but I understand your point of view to discontinue this support. After I don’t know too much on meteor and such thing but it’s not really complicated to have a property somewhere that set the contextPath, a lot of applications / framework permits to manage that.
After to provide an argument to keep the possibility to install on a subdirectory is that on some webhost you don’t have the possibility to manage subdomains and certificates, you are limited on what the webhost provide you ! In this case you need to manage all your app install by subdirectories !
An other question, I didn’t succeed also to use a same instance of Rochet.chat on several serverName, this isn’t also a possibility ? Rocket.Chat can’t use the X-Forwarded-Proto and X-Forwarded-Host provided by a proxy server instead of setting it as fixed by UI / env variable ? This would be really appreciated too.
After to provide an argument to keep the possibility to install on a subdirectory is that on some webhost you don’t have the possibility to manage subdomains and certificates, you are limited on what the webhost provide you ! In this case you need to manage all your app install by subdirectories !
Webhost that limits you this way are not competitive and dying fast. I would be surprised if you cannot find a more flexible web hosting firm at a lower cost. Which webhost are you with that still have such restriction?
An other question, I didn’t succeed also to use a same instance of Rochet.chat on several serverName, this isn’t also a possibility ? Rocket.Chat can’t use the X-Forwarded-Proto and X-Forwarded-Host provided by a proxy server instead of setting it as fixed by UI / env variable ? This would be really appreciated too.
Webhost that limits you this way are not competitive and dying fast. I would be surprised if you cannot find a more flexible web hosting firm at a lower cost. Which webhost are you with that still have such restriction?
I’m not using a such host, but I know it exist as I already encounter it and changed due to that restriction And it’s really low cost host.
After on my side we have our own servers, and we are deploying apps by subdirectories, but for several server names as we link a user auth on a domain it’s more easy to keep him on the good server name. But we can tune our servers and apps for a such case with some development for our customization needs, even if we prefer to avoid such cost.
For the server name management part I will follow your advice
In fact as long as OAuth is supported so I think our requirements will be fulfilled after you take subfolders out. Only one challenge we need to fix
So RC is a part of our community site and our biggest issue was in the login page customize to avoid feeling the user that he is navigating from our site to another system.
Initially, what we did is to add our own custom OAuth provider. We disabled all kind of the authentications and we kept only our custom OAuth. Then we expected the login page will not appear at all and user will be redirect automatically to our site to generate the access token. However what was happened is the rocket chat login page keep showing with only one button that is representing our custom OAuth provider
To overcome that we used the IframeAuthentication which also contains lot of issues because of cross domain iframe security, in fact it was impossible for some browser to use it
Finaly to we came up with deployint it at subfolder to overcome the browser security and be able to allow user login without that Rocket Chat login page
What I am suggesting here after to take subfolder out, we need more control on the login page without iframe in place at all.
For example we can have an option to configure what is the default authentication provider to be used instead of letting the user see the RC login page and click on a button single button representing our Custom OAuth
I want to host rocket chat and jitsi-meet on a single server at home. My ISP uses CGNAT so my router does not have a public IP address. I can circumvent this using https://devhub.io/repos/beameio-beame-insta-ssl, but they only provide one free generated subdomain and SSL certificate to connect to my network. Jitsi-meet will not run in a sub-folder, so your proposal would make it impossible for me to host rocket.chat as well without incurring subscription fees.
At first glance, this seems like a knee-jerk reaction. It shouldn’t be that difficult to make sure that PRs which link to resources on the server, should start with a baseUrl. Is it really necessary to kill such a fundamental piece of functionality, just for the reasons stated?
@sing.li, you have responded kindly to everyone’s concerns, and with valid suggestions and alternatives. However, there are a million ways to fix a problem, but IMO hosting in a subdirectory is not a “problem” that should be “fixed”.
@joshm_tg I totally agree with you, it is for sure depending on how you providing your solutions so you may have some different reasons other than what I have.
I am just stating what we are facing because as you know in the modern applications any system can have different subsystems with different urls as long as the end user has a smooth SSO authentication mechanism among all of these subsystem
And it’s really low cost host.